diff options
Diffstat (limited to 'gitlab/issues/target_i386/host_missing/accel_WHPX')
10 files changed, 318 insertions, 0 deletions
diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/1031.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/1031.toml new file mode 100644 index 00000000..6d810d3f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/1031.toml @@ -0,0 +1,50 @@ +id = 1031 +title = "Intel 12th Gen CPU not working with QEMU Hyper-V nested virtualization" +state = "opened" +created_at = "2022-05-19T13:42:11.330Z" +closed_at = "n/a" +labels = ["accel: WHPX", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1031" +host-os = "Manjaro" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 7.0.0" +guest-os = "Windows 10" +guest-arch = "x86_64" +description = """When booting with Hyper-V + host-passthrough it gets stuck at tianocore, does not change until I reboot which then loops into windows diagnostics which leads nowhere. Done using Windows 10, tried using newest windows version and 1909. + +Specs: Manjaro Gnome 5.15 LTS, i5-12600k, z690 gigabyte aorus elite ddr4, rtx 3070ti. + +I’ve spent days trying to figure out what was messing with it and it turned out I could boot when messing with my CPU topology, for some reason my 12th gen + Hyper-V + host-passthrough only works with sockets. Cores and threads above 1 causes boot problems, apart from disabling vme which boots, but the hypervisor does not load. + +This fails (normal host-passthrough): +``` + <cpu mode="host-passthrough" check="none" migratable="on"> + <topology sockets="1" dies="1" cores="6" threads="2"/> + </cpu> +``` + +This boots (-can only change sockets): +``` + <cpu mode="host-passthrough" check="none" migratable="on"> + <topology sockets="12" dies="1" cores="1" threads="1"/> + </cpu> +``` + +This boots (-no hypervisor): +``` +<cpu mode="host-passthrough" check="partial" migratable="off"> + <topology sockets="1" dies="1" cores="6" threads="2"/> + <feature policy="disable" name="vme"/> + </cpu> +``` + +No matter what adjustment I do I cannot change the cores or threads or it will result in a boot failure, host-model just does not work once I boot the machine the host model changes to cooperlake. + +My current way of bypassing this is I’ve downloaded the QEMU source code, gone through cpu.c and modified the default skylake-client CPU model to match my CPU, then I added in most of my i5-12600k flags manually, this seems to work with a 35-45% performance drop in CPU and in ram. Without Hyper-V enabled and using the normal host-passthrough I get near bare metal performance. + +Tried with multiple versions of QEMU, EDK2, and loads of kernel versions (to add to this my i5-12600k gen does not work on kernel version 5.13 and below) even went ahead to try Ubuntu and had the same problem, my other (i7-9700k) PC works fine with Hyper-V. Also disabled my E-cores through bios resulting in the same issue. CPU pinning the P-cores to the guest does not seem to help.""" +reproduce = """1. Enable hyper-v in windows features +2. Restart guest +3. Boot failure""" +additional = """Hyper-V host-passthrough XML: +https://pst.klgrth.io/paste/yc5wk""" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/1043.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/1043.toml new file mode 100644 index 00000000..ac067516 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/1043.toml @@ -0,0 +1,20 @@ +id = 1043 +title = "QEMU cpu max doesnot work on Windows 11 with ryzen processor and whpx" +state = "opened" +created_at = "2022-05-28T00:24:11.657Z" +closed_at = "n/a" +labels = ["accel: WHPX", "hostos: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1043" +host-os = "(Windows 11)" +host-arch = "(x86)" +qemu-version = "(v7.0.0-11902-g1d935f4a02-dirty & v7.0.0-1245-g58b53669e8)" +guest-os = "(any)" +guest-arch = "(x86)" +description = """- System does not boot. +- WHPX: setting APIC emulation mode in the hypervisor +- Windows Hypervisor Platform accelerator is operational +- whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005) +- qemu: WHPX: Unexpected VP exit code 4""" +reproduce = """1. Windows 11 / Ryzen +2. qemu-system-x86_64.exe --accel whpx --cpu max""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/1137.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/1137.toml new file mode 100644 index 00000000..c58be8d4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/1137.toml @@ -0,0 +1,43 @@ +id = 1137 +title = "When using qemu-system-x86_64 whpx acceleration, cpu information is set strangely." +state = "opened" +created_at = "2022-08-02T03:33:08.092Z" +closed_at = "n/a" +labels = ["accel: WHPX", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1137" +host-os = "Windows 11" +host-arch = "x86_64" +qemu-version = "7.0.0" +guest-os = "Windows 10 or Windows 11 or Linux.. etc" +guest-arch = "x86_64" +description = """When using the guest with whpx acceleration in qemu-system-x86_64, the CPU information of the guest seems to be set strangely. + +When the guest is Linux, it seems that individual CPUs are allocated as many as the number of cores when using the -accel whpx option and the -smp option. +* -smp 4, -smp cores=4, -smp sockes=1, cores=4, threads=1 are all set to have 4 single-core CPUs plugged in + +If the guest is Windows, check the information with CPU-Z + It is recognized as a Pentium 4 and is displayed as a CPU with 1 core and n threads. + +Physically, it seems to be set to have n individual CPUs with 1 core plugged in. +In Windows 11 Home (which seems to be the case for all versions of Windows Home), you cannot give the -smp value more than 5. +* When booting with the -smp option value of 5 or more, a BSOD saying multiprocessor configuration not supported appears. -smp n, -smp cores=n, -smp sockes=1,cores=n,threads=1 All same symptoms occur""" +reproduce = """1. Boot Windows or Linux with -accel whpx -smp 4 option (or with the -accel whpx -smp sockets=1,cores=4,threads=1 option to make it deterministic) +2. For Linux guest, use cat /proc/cpuinfo to check cpu information, for Windows guest, use cpu-z, device manager, task manager, etc. to check cpu information +3. In the information of the Linux guest, it is displayed as fixed as core id : 0, cpu cores : 1, + In Windows guest, information is displayed as written in "Description of problem" respectively.""" +additional = """**Windows 11 Home Guest set to 4 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + + + +**Windows 11 Home Guest set to 5 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=5,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + + + +**Linux (Debian 11) guest set to 4 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 4g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="debian.vdi",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx +""" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/2063.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/2063.toml new file mode 100644 index 00000000..fd62f95b --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/2063.toml @@ -0,0 +1,67 @@ +id = 2063 +title = "Poor performance with -accel whpx on Server 2022 host, windows 10 guest - missing CPUID hypervisor ident data?" +state = "opened" +created_at = "2023-12-30T23:23:02.500Z" +closed_at = "n/a" +labels = ["accel: WHPX", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2063" +host-os = "Windows Server 2022" +host-arch = "x86-64" +qemu-version = "QEMU emulator version 8.2.0 (v8.2.0-12045-g3d58f9b5c5)" +guest-os = "Windows 10" +guest-arch = "x86-64" +description = """**Performance of Windows 10 x64 QEMU virtual machine is essentially unusable, compared to same image running under Hyper-V on the same host system.** + +It appears the VM is not being provided the Hyper-V enlightenment hints while running under QEMU. The hv-XXX cpu options do not appear applicable to -accel WHPX. + +Below are dumps of the 0x40000000 cpuid values on the host, QEMU guest, and Hyper-V guest (exact same .VHD file used, nested virtualization not enabled for this VM). + +host: +- 0x40000000 eax=4000000c ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=bfff ebx=2bb9ff ecx=22 edx=71fffbf6 +- 0x40000004 eax=50d1c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=400 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=1e00be ebx=0 ecx=0 edx=0 +- 0x40000007 eax=80000007 ebx=3 ecx=0 edx=0 +- 0x40000008 eax=100001 ebx=1 ecx=aaaa edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 + +qemu guest with -accel whpx : +- 0x40000000 eax=40000010 ebx=0 ecx=0 edx=0 +- 0x40000001 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000003 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000004 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000005 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000006 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000d eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000e eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000f eax=0 ebx=0 ecx=0 edx=0 +- 0x40000010 eax=225519 ebx=30d40 ecx=0 edx=0 + +hyperv guest VM: (nested virtualization not enabled) +- 0x40000000 eax=4000000b ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=ae7f ebx=388030 ecx=22 edx=e0bed7b2 +- 0x40000004 eax=40c2c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=f0 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=e ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/2403.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/2403.toml new file mode 100644 index 00000000..818d67f7 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/2403.toml @@ -0,0 +1,22 @@ +id = 2403 +title = "WHPX accelerator fails to boot guest Windows 7" +state = "opened" +created_at = "2024-06-21T12:38:27.774Z" +closed_at = "n/a" +labels = ["accel: WHPX", "kind::Bug", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2403" +host-os = "Windows 11 23H2" +host-arch = "x64" +qemu-version = "v9.0.0-12054-g923cf646f4" +guest-os = "Windows 7" +guest-arch = "x64" +description = """I get Qemu freezed on Starting Windows screen when trying to boot Windows 7 Professional""" +reproduce = """1. Run qemu with the above command line and until Starting Windows screen appears. +2. See qemu freezed.""" +additional = """tcg accelerator works ok, though (Windows 7 successfully boots as expected on native hardware): + +- `qemu-system-x86_64.exe -accel tcg -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -m 4G -machine q35 -device qxl-vga,vgamem_mb=64 -hda Windows7_Disk.qcow2 -boot d -cdrom Windows7.iso` + + This bug seems to have the same roots: https://gitlab.com/qemu-project/qemu/-/issues/1859 + + {width=579 height=477}""" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/2782.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/2782.toml new file mode 100644 index 00000000..fcd870ed --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/2782.toml @@ -0,0 +1,18 @@ +id = 2782 +title = "WHPX won't enable x86_64v3 level instructions" +state = "opened" +created_at = "2025-01-17T16:57:44.955Z" +closed_at = "n/a" +labels = ["accel: WHPX", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2782" +host-os = "Windows 11" +host-arch = "x86_64" +qemu-version = "9.2.0" +guest-os = "Fedora 41" +guest-arch = "x86_64" +description = """x86_64v3 support is not available inside guest""" +reproduce = """1. Boot the image +2. Open terminal +3. Run `/lib64/ld-linux-x86-64.so.2 --help` and check which levels are available in the output +4. Or run `/lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep isa` and check `isa_1` value (expected 7 for v3 (3 bits being set))""" +additional = """Due to this some Linux distribution, like Centos Stream 10, will not be able to boot with WHPX acceleration enabled.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/346.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/346.toml new file mode 100644 index 00000000..0ed988cd --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/346.toml @@ -0,0 +1,15 @@ +id = 346 +title = "Guest refuses to accept keyboard input when accelerated with WHPX" +state = "opened" +created_at = "2021-05-21T03:36:26.261Z" +closed_at = "n/a" +labels = ["Documentation", "accel: WHPX", "device:input", "hostos: Windows", "kind::Bug", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/346" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/513.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/513.toml new file mode 100644 index 00000000..56e694b1 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/513.toml @@ -0,0 +1,15 @@ +id = 513 +title = "Qemu/WHPX fails on applying UEFI firmware with -pflash" +state = "opened" +created_at = "2021-08-04T04:23:25.471Z" +closed_at = "n/a" +labels = ["accel: WHPX", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/513" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/934.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/934.toml new file mode 100644 index 00000000..63e85b3f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/934.toml @@ -0,0 +1,53 @@ +id = 934 +title = "VM execution fails for tianocore edk2 ovmf uefi based image on windows whpx" +state = "opened" +created_at = "2022-03-24T07:07:08.822Z" +closed_at = "n/a" +labels = ["accel: WHPX", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/934" +host-os = "Windows 10 21H2 19044.1586" +host-arch = "x86_64" +qemu-version = "``QEMU emulator version 6.2.0 (v6.2.0-11889-g5b72bf03f5-dirty)``` ```QEMU emulator version 7.0.0 (v7.0.0-11902-g1d935f4a02-dirty)``" +guest-os = "installed of Fedora-36 beta" +guest-arch = "x86_64" +description = """Cannot do a UEFI tianocore boot of image with linux installation. + +I think the BIOS/UEFI/firmware when run inside a virtual-machine should be oblivious to the type of hypervisor, just probe and enable the emulated hardware. Maybe WHPX is not enabling pflash devices properly. + +My goal is to create a 40Gb fedora linux image with a on-image UEFI boot sequence that I can +1. native boot using ventoy (works) +2. boot using kvm/qemu in linux (works) +3. boot using whpx/qemu in windows (no success yet) + +My original sequence of steps to reproduce was. +1. Under Linux, in qemu-vm, create a bootable linux image by installing from the fedora livecd installer +2. Confirm qemu-VM/fedora installation/UEFI boot works fine under Linux/kvm/qemu. One can see tianocore logo booting up. +3. reboot to windows +4. attempt to boot with analogous windows qemu command. confirm boot failure and error message +5. remove ```-accel whpx``` and rerun, confirm boot succeeds with tianocore image, albeit un-accelarated + +It turns out the image creation is not required. + +The below works under linux +``` +XDG_RUNTIME_DIR=/run/user/1000 qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/OVMF_VARS.fd" -drive "index=2,format=raw,file=/vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy" -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait +``` +The below does not work under windows +``` +qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" -drive "index=1,if=pflash,format=raw,file=E:/vstorage/OVMF_VARS.fd" -drive "index=2,if=virtio,media=disk,format=raw,file=H:\\m01_lnx.raw.img" -drive "index=3,if=virtio,media=disk,format=raw,file=H:\\gkpics01.raw.img" -drive "index=4,if=virtio,media=disk,format=vhdx,file=E:\\test\\sgdata.vhdx" -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15 -device virtio-net,netdev=vmnic1 -qmp "tcp:127.0.0.1:5955,server,nowait" +: +Windows Hypervisor Platform accelerator is operational +qemu-system-x86_64: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64: WHPX: Failed to exec a virtual processor +``` + +The image does boot if one removes the hardware hypervisor argument ```-accel whpx```""" +reproduce = """The full qemu command with disk images is not required. Just the accel whpx and the pflash devices are sufficient. +1. Confirm that the VM does not execute with the command +``` +qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -boot c -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" +``` +2. Confirm that the VM does execute and tianocore logo shoes up when ```-accel whpx ``` is removed.""" +additional = """- In the planned changes of Fedora 37, going forward, fedora installer will no longer support installing fresh to machines with legacy BIOS and will necessarily require UEFI boot. This means that there is urgency in allowing this mode of booting. + - https://fedoraproject.org/wiki/Releases/37/ChangeSet + - https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS""" diff --git a/gitlab/issues/target_i386/host_missing/accel_WHPX/977.toml b/gitlab/issues/target_i386/host_missing/accel_WHPX/977.toml new file mode 100644 index 00000000..61a9b799 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_WHPX/977.toml @@ -0,0 +1,15 @@ +id = 977 +title = "QEMU 6.2, windows 98 doesn't shutdown properly" +state = "opened" +created_at = "2022-04-12T09:03:05.024Z" +closed_at = "n/a" +labels = ["accel: WHPX", "target: i386", "workflow::Needs Info"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/977" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" |