VCPU shutdown request with HAX In most scenarios when turning on HAX, QEMU will exit, printing "VCPU shutdown request" to the console. This is on Windows 8.1 with Intel HAXM 7.5.2. QEMU's -version prints v4.1.0-11789-g013a2ecf4f-dirty . I've used an installer from qemu.weilnetz.de. The host CPU is an IvyBridge i5 (mobile). Some notes: Win10-1709-PE_Custom.iso is a custom WinPE image I had meant to test using QEMU. It is likely broken and doesn't boot at all. [Stuck, etc.]: I had given that image almost 2h during which the circle of dots continued to spin. I don't know if it or QEMU did anything of interest at all during that period, but this might indicate long-term stability, sort of. Win10_1709_German_x32.iso: Stock Win10 1709 32bit ISO I got off a German tech website. I've waited for the install screen to appear. TinyCore_10-1.iso: TinyCore by Core Project. A 18MB graphical Linux distribution, pretty barren by default. I've generally opened Apps there, the package manager, then shut it down again. On the one marked [Fx stable], I've gotten Firefox 60.8.0 ESR and visited a couple of websites. (I don't know of any available program that would try to execute exotic CPU instructions in weird combinations to do a proper test.) Q64 is .\qemu-system-x86_64.exe , substituted for readability (shorter lines). First, those that QEMU seemed to handle well: Q64 -machine q35 -accel hax Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso Q64 -machine q35 -cdrom \!S\Win10-1709-PE_Custom.iso -m 4096 [Stuck, etc.] Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 1920 Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 256 [1] Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -cpu max -m 512 Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu max -serial file:\!S\QEMU_TCL_BUG.log [2] Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax [Fx stable, s.a.] Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Skylake-Client-IBRS Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Icelake-Client-v1 Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Cascadelake-Server-v2 Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu Broadwell-v4 Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu IvyBridge-IBRS Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu coreduo Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu pentium Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu base [3] Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu base [4] Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -cpu pentium Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 [5] Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Broadwell-v4 [5] Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 [5] Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo Then, those that made it print "VCPU shutdown request" repeatedly and quit, immediately or after a couple of seconds at most, except where noted. I put an indication of the number of messages into curly braces. Q64 -machine q35,accel=hax -cpu max {many} Q64 -machine q35,accel=hax -cdrom \!S\Win10-1709-PE_Custom.iso Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax {very many} Q64 -machine q35 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax -cpu max {very many} Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -accel hax {just two} Q64 -cdrom \!S\TinyCore_10-1.iso -m 512 -accel hax -cpu max {a couple} Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu Icelake-Client-v1 -accel hax {two} Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu IvyBridge-v1 -accel hax {two} Q64 -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu pentium -accel hax {three} .\qemu-system-x86_64.exe -cdrom \!S\Win10_1709_German_x32.iso -m 512 -cpu coreduo -accel hax {a few} (I have rewritten a couple of commandlines to make them more uniform (changing the placement of parameters and using '-accel hax' instead of '-machine ...,accel=hax').) [1]: WinPE boot error, not enough RAM. [2]: Will cause a kernel BUG: "... \ login[892]: root login on 'tty1' \ BUG: unable to handle kernel paging request at 00010ffa \ ...". See attached file. [3]: Stuck after "Booting the kernel.", cursor blinks. [4]: Stuck at blinking console prompt, no input possible. [5]: According to the printout, TCG doesn't support a bunch of those processor's features that have been requested. Thanks for testing. I think that some of those problems might be issues of the Intel HAXM driver, so I suggest to report them at https://github.com/intel/haxm/issues. As stated on https://qemu.weilnetz.de/FAQ, I consider HAXM support as experimental and suggest to try WHPX which is also experimental, but seems to have less limitations and run more stable. Ahh, yeah, the FAQ ...! :D A lot of work testing stuff and then I forgot about that. (I _did_ have a look into it when I wondered about the binaries whose name ends with a W.) Anyways, WHPX is not available for Win8.1, but only starting with Win10 _1803_, they say: https://docs.microsoft.com/en-us/xamarin/android/get-started/installation/android-emulator/hardware-acceleration?pivots=windows#accelerating-with-hyper-v And indeed, '.\qemu-system-x86_64.exe -accel whpx' will return ...\qemu-system-x86_64.exe: Could not load library WinHvPlatform.dll. ...\qemu-system-x86_64.exe: failed to initialize WHPX: Function not implemented Fortunately enough I do have Win10 1803 in dual-boot on this machine. Let's see how it goes!* *[At this point, I could have saved this message, switched OS and tried it, such that I could write about the outcome here, but that wouldn't really belong to this bug, so instead, I'll send this first and then I'll maybe file a fresh bug if WHPX doesn't work either. ;) ] The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. [Expired for QEMU because there has been no activity for 60 days.]