New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot start ubuntu, archlinux ... with hax #74

Closed
fsmoke opened this Issue Jul 11, 2018 · 13 comments

Comments

Projects
None yet
5 participants
@fsmoke
Copy link

fsmoke commented Jul 11, 2018

I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does not works when i turn on hax acceleration. Permanent kernel panics, black screen freezing and other crashes happens when i run qemu.
Qemu crashed with hax - when i ran it from iso. It crashed on already installed system - it's not matters.

Versions:
archlinux-2018.07.01-x86_64
ubuntu-18.04-live-server-amd64.iso

I run qemu-system-x86_64.exe binary.

qemu-system-x86_64.exe -drive file=build_slave.img,index=0,media=disk,format=qcow2 -m 2G -accel hax -name build_slave

My CPU:
core i7 2600k

My Host:
Windows 7 64bit

2018-07-11_15-49-15

@raphaelning

This comment has been minimized.

Copy link
Contributor

raphaelning commented Jul 11, 2018

Thanks for the report. I don't think we have ever tested an Arch Linux image, so you've probably discovered a HAXM bug. We'll see if we can reproduce this issue on our side tomorrow.

@raphaelning raphaelning added the bug label Jul 11, 2018

@fsmoke

This comment has been minimized.

Copy link

fsmoke commented Jul 11, 2018

Thank you for fast answer. So i decided to help you to avoid from full install process of archlinux.

below my build_slave.img packed by 7z and uploaded to yandex disk( it's about ~500mb in archive and 1.8gb unpacked)
build_slave.7z

system not clean - i already installed some packages(of course with tcg accel) - but it's don't matters

besides i am developer too - and have mvs on my pc - so i decided to build latest IntelHasm driver myself and test it. But nothing changed, after i replace IntelHaxm.sys in my system directory and reboot. :(

Maybe i did something wrong..?

@fsmoke

This comment has been minimized.

Copy link

fsmoke commented Jul 11, 2018

I forgot: host machine is win 7 64bit

@fsmoke

This comment has been minimized.

Copy link

fsmoke commented Jul 11, 2018

As i say i tried ubuntu 18.04 - i installed it with tcg accel, redirected console to ttyS0(to make log) and then turn on hax - and got... very similar kernel panic

So even folk ubuntu - not works :(

i attach this log here:
run.log

@fsmoke fsmoke closed this Jul 11, 2018

@fsmoke fsmoke reopened this Jul 11, 2018

@dzyong

This comment has been minimized.

Copy link

dzyong commented Jul 12, 2018

It seems like the same issue as #39.
I met this too on Ubuntu 18.04 and the latest Debian.

@roc007

This comment has been minimized.

Copy link

roc007 commented Jul 12, 2018

I have the same issue on the host Windows 7 64bits, qemu 2.12 haxm 7.2.0 with the guest archlinux 2018.07.01

qemu_hax_bug

@junxiaoc

This comment has been minimized.

Copy link
Contributor

junxiaoc commented Jul 12, 2018

We could reproduce this issue with attached build_slave.7z. But unfortunately there is no error/warning log in haxm driver when kernel panic happens. We are looking for reasons about what might introduce this issue in haxm.

@raphaelning

This comment has been minimized.

Copy link
Contributor

raphaelning commented Jul 12, 2018

But nothing changed, after i replace IntelHaxm.sys in my system directory and reboot. :(

64-bit Windows 7 won't load a driver unless it's got a legitimate digital signature. When you build HAXM yourself using the Debug build configuration, you only get either a test-signed binary, which is not trusted by Windows. The only way to remove that restriction is to turn on Test Mode.

You could try a fairly recent 64-bit IntelHaxm.sys that we built and signed a few weeks ago:

#40 (comment)

@fsmoke

This comment has been minimized.

Copy link

fsmoke commented Jul 12, 2018

I have test sign mode turned on permanently in my system(cos i developed (and still support) some win driver)- just forgot to say.

@raphaelning

This comment has been minimized.

Copy link
Contributor

raphaelning commented Jul 12, 2018

That's great. I'd still recommend that you check out that link and follow the instructions there to download HaxmLoader.exe, which can also be used to load the IntelHaxm.sys you built.

@fsmoke

This comment has been minimized.

Copy link

fsmoke commented Jul 12, 2018

just now I tested driver from issue #40 - bad luck - behavior identical :(

@junxiaoc

This comment has been minimized.

Copy link
Contributor

junxiaoc commented Jul 24, 2018

We are still working on this issue, and try to narrow down that which guest OS behavior might introduce haxm handling error.

@junxiaoc

This comment has been minimized.

Copy link
Contributor

junxiaoc commented Jul 26, 2018

It looks issue is related with SSE instructions support. We are working on fix.

junxiaoc added a commit that referenced this issue Jul 31, 2018

core: save/restore FPU registers in VM entry/exit
Guest OS kernel/app might use SSE instruction and registers.
When Guest OS VMM exits, these registers should be saved, or else
it might be corrupted by host OS/app. In next time guest VMM
enter, guest's SSE registers context might be corrupted.

Guest app segment fault, coredump, and kernel panic were reported
which should be related with this issue.

This change is to remove is_fpu_used flag so guest FPU registers
could be saved in VM exit and restored in VM enter unconditionally.

Fixes #39, fixes #74.

junxiaoc added a commit that referenced this issue Aug 1, 2018

core: save/restore FPU registers in VM entry/exit
Guest OS kernel/app might use SSE instruction and registers.
When Guest OS VMM exits, these registers should be saved, or else
it might be corrupted by host OS/app. In next time VM entry,
guest's SSE registers context might be corrupted.

Guest app segfault and kernel panic were reported which should
be related with this issue.

This change is to remove is_fpu_used flag so guest FPU registers
could be saved in VM exit and restored in VM entry unconditionally.

Fixes #39, fixes #74.

junxiaoc added a commit that referenced this issue Aug 1, 2018

core: save/restore FPU registers in VM entry/exit
Guest OS kernel/app might use SSE instruction and registers.
When Guest OS VM exits, these registers should be saved, or else
it might be corrupted by host OS/app. In next time VM entry,
guest's SSE registers context might be corrupted.

Guest app segfault and kernel panic were reported which should
be related with this issue.

This change is to remove is_fpu_used flag so guest FPU registers
could be saved in VM exit and restored in VM entry unconditionally.

Fixes #39, fixes #74.

junxiaoc added a commit that referenced this issue Aug 1, 2018

core: save/restore FPU registers in VM entry/exit
Guest OS kernel/app might use SSE instruction and registers.
When Guest OS VM exits, these registers should be saved, or else
it might be corrupted by host OS/app. In next time VM entry,
guest's SSE registers context might be corrupted.

Guest app segfault and kernel panic were reported which should
be related with this issue.

This change is to remove is_fpu_used flag so guest FPU registers
could be saved in VM exit and restored in VM entry unconditionally.

Fixes #39, fixes #74.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment