diff options
Diffstat (limited to 'results/classifier/118/none/1846392')
| -rw-r--r-- | results/classifier/118/none/1846392 | 129 |
1 files changed, 129 insertions, 0 deletions
diff --git a/results/classifier/118/none/1846392 b/results/classifier/118/none/1846392 new file mode 100644 index 000000000..a0e2cfb7d --- /dev/null +++ b/results/classifier/118/none/1846392 @@ -0,0 +1,129 @@ +graphic: 0.761 +user-level: 0.733 +KVM: 0.727 +performance: 0.723 +risc-v: 0.717 +TCG: 0.699 +hypervisor: 0.696 +permissions: 0.689 +debug: 0.664 +ppc: 0.654 +vnc: 0.644 +network: 0.635 +device: 0.633 +semantic: 0.629 +register: 0.628 +peripherals: 0.626 +assembly: 0.620 +x86: 0.611 +architecture: 0.609 +PID: 0.603 +files: 0.599 +socket: 0.598 +VMM: 0.596 +kernel: 0.571 +virtual: 0.550 +mistranslation: 0.546 +arm: 0.530 +boot: 0.496 +i386: 0.368 + +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.] + |