VCPU shutdown request with HAX

[Rhodus]

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 miscellaneous notes (you can skip them first):
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).

Invocations that QEMU seemed to handle well (without the headline error):
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}
Q64 -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.

PS: There should be some note highlighting that there is a strict limit on line length (or at least that's what it looks like). I can shorten the file names further to enhance skimmability ... :/
Also, let me know if you need anything else.

[Stefan Weil (ubuntu-weilnetz)]

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.

[Rhodus (rhodus)]

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. ;) ]

[Thomas Huth (th-huth)]

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.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]