diff options
Diffstat (limited to 'results/classifier/118/permissions/1821595')
| -rw-r--r-- | results/classifier/118/permissions/1821595 | 157 |
1 files changed, 157 insertions, 0 deletions
diff --git a/results/classifier/118/permissions/1821595 b/results/classifier/118/permissions/1821595 new file mode 100644 index 000000000..21673f4b3 --- /dev/null +++ b/results/classifier/118/permissions/1821595 @@ -0,0 +1,157 @@ +permissions: 0.907 +user-level: 0.874 +semantic: 0.844 +device: 0.842 +virtual: 0.837 +register: 0.825 +assembly: 0.824 +debug: 0.819 +architecture: 0.812 +graphic: 0.804 +performance: 0.797 +hypervisor: 0.791 +mistranslation: 0.790 +risc-v: 0.787 +arm: 0.774 +PID: 0.755 +vnc: 0.755 +VMM: 0.753 +files: 0.740 +socket: 0.735 +peripherals: 0.725 +ppc: 0.722 +boot: 0.698 +KVM: 0.684 +kernel: 0.665 +network: 0.644 +TCG: 0.536 +x86: 0.525 +i386: 0.522 + +Failed to emulate MMIO access with EmulatorReturnStatus: 2 + +I have compiled qemu with enable-whpx parameter for Hyper-V Platform API in Mingw64 . When I tried run with Windows 7 iso file I have faced issue with the following problem: +qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor + + +configuration directives: + +../configure --target-list=x86_64-softmmu,i386-softmmu --enable-lzo\ + --enable-bzip2 --enable-tools --enable-sdl --enable-gtk --enable-hax\ + --enable-vdi --enable-qcow1 --enable-whpx --disable-capstone\ + --disable-werror --disable-stack-protector --prefix="../../QEMU-bin" + + +Qemu command line: +qemu-system-x86_64.exe -m 1024 -cdrom "C:\Users\vmcs\Documents\en_windows_7_home_premium_with_sp1_x86_dvd_u_676701.iso" -display sdl -machine q35 -accel whpx + +Hi, + +Having a similar issue here, running "QEMU emulator version 4.2.91 (v5.0.0-rc1-31-g146aa0f104-dirty)" + +Configuration / build command line, +./configure --cross-prefix=x86_64-w64-mingw32- --target-list=x86_64-softmmu --enable-whpx --enable-fdt --enable-gtk --enable-vnc --disable-pie --enable-opengl && make -j16 && make -j16 installer + +And the QEMU command line, +qemu-system-x86_64.exe \ + -m 2G \ + -machine q35 \ + -cpu Penryn \ + -accel whpx \ + -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ + -smbios type=2 \ + -drive if=pflash,format=raw,readonly,file="./firmware/OVMF_CODE.fd"\ + -drive if=pflash,format=raw,file="./firmware/OVMF_VARS-1024x768.fd" \ + -usb -device usb-kbd -device usb-mouse \ + -netdev user,id=net0 \ + -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 \ + -device ich9-ahci,id=sata \ + -drive id=ESP,if=none,format=qcow2,file=ESP.qcow2 \ + -device ide-hd,bus=sata.2,drive=ESP \ + -drive id=InstallMedia,format=raw,if=none,file=BaseSystem.img \ + -device ide-hd,bus=sata.3,drive=InstallMedia \ + -drive id=SystemDisk,if=none,file=MyDisk.qcow2 \ + -device ide-hd,bus=sata.4,drive=SystemDisk \ + + +If I remove (only), -accel whpx \ => Then it all runs, just very slowly ;-). + +Any suggestions, things to try? + +Thanks! + +FYI, I was curious if this was a Ryzen issue or not (which I am running), so I tried another machine - here are the two combos I tried, +1) Ryzen 5 2600X, Windows 19041.172 +2) Core i5-6600K, Windows 18363.720 + +Same issue on both. + +Thanks! + +Which OS do you try with qemu? IIRC Windows 10 should work well with WHPX. Also,this issue is qemu depended that they don't handle specific MMIO instruction/exit. + +Sorry for the typo. I should have mentioned that this issue is WHPX related. I have created an issue in WHPX Github page about it. + +As far as I can tell QEMU just hands this off to the whpx emulation sub-system: + + https://docs.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation + +Basically what is happening is the guest has tried to access I/O space and trapped back to QEMU which then passes the instruction back to the whpx support library to decode and emulate. + +Hi, + +I tried backing up ... nothing but startup and UEFI (i.e. no OS, just get to the EFI Shell). Can't even get there ... does that make sense? + +Thanks! + +I think WHPX can't some MMIO requests for EFI. + +Folks seem to think this is the fix, +https://stackoverflow.com/questions/55197032/android-emulator-whpx-failed-to-emulate-mmio-access-exit-code-3 + +But it's not working for me ... does it help you? + +Thanks! + +And here, +https://www.reddit.com/r/androiddev/comments/c7u6h2/android_virtual_device_on_ryzen/ + + +I don't think QEMU can do anything to fix this - you need to build against a new library. + +Sorry, not quite following your comment - but it's likely me :-(. + +I assume you mean QEMU - but build against what upstream library? I ask because for QEMU to build, only the three header files from Windows are copied over, and then it calls / uses the dll's (libraries) in Windows itself ... right? FYI, I'm running Windows 19041.172, to try to make sure I do have the latest related to whpx. + +Thanks! + +Hi, + +I built against the latest library I could (Windows Insider Preview, SDK) - same failure. + +Thoughts? + +Thanks! + +Should say - I rebuilt (today). Still no joy. + +Hi. I didnt build Qemu but I downloaded the last version 5.1.0 from https://qemu.weilnetz.de/w64/ and the error "Failed to emulate MMIO access with EmulatorReturnStatus: 2" happens when I use -drive if=pflash or -pflash with -accel whpx. + +"qemu-system-x86_64.exe -pflash d:\macWIN\OVMF_CODE.fd -accel whpx +Windows Hypervisor Platform accelerator is operational +qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor" + + +If I remove pflash and change to -bios "ovmf" the machine works. +qemu-system-x86_64.exe -bios d:\macWIN\OVMF_CODE.fd -accel whpx + +If I maintain pflash but remove -accel whpx the machine works too. +qemu-system-x86_64.exe -pflash d:\macWIN\OVMF_CODE.fd + +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 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.] + |