Accelerating QEMU on Windows host OS

[valinet]

I did some experiments today. The goal was to see whether this can be accelerated a bit to have it work faster under Windows 10 host OS. I used QEMU 8.2.0 (as reported by qemu-system-x86_64.exe -version) already compiled from here (latest version available at the time of writing), as recommended on QEMU's official web site. I observed the boot up time of the Alpine Linux install when invoking qemu-system-x86_64.exe with various parameters. The laptop I did the testing on (Dell XPS 15 7590) was running on battery power, and I have performed the tests on "Better battery, "Better performance", and "Best performance" power profiles. The machine has the Intel Core i7-9750H CPU and "Windows Subsystem for Linux" (not necessarily required), "Hyper-V" (not required), and "Windows Hypervisor Platform" are enabled in "Turn Windows features on or off". ver on host OS reports Microsoft Windows [Version 10.0.19044.4046].

qemu-system-x86_64.exe -nographic -m 512 -nic user -hda alpine.qcow2

Boot-up time:

• 1min28sec ("Better battery")
• 1min ("Better performance")
• 44sec ("Best performance")

qemu-system-x86_64.exe -accel whpx -m 512 -nic user -hda alpine.qcow2

This did not work. The output from QEMU showed this:

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)

Apparently, there is a long standing bug in QEMU regarding this, here. The workaround is to run the command like this:

qemu-system-x86_64.exe -nographic -accel whpx,kernel-irqchip=off -m 512 -nic user -hda alpine.qcow2

Boot-up time:

• 1min12sec ("Better battery")
• 51sec ("Better performance")
• 33sec ("Best performance")

That is still quite slow. I looked around a bit and some people suggested using -machine q35 here:

qemu-system-x86_64.exe -nographic -machine q35 -accel whpx,kernel-irqchip=off -m 512 -nic user -hda alpine.qcow2

Boot-up time:

• 21sec ("Better battery")
• 19sec ("Better performance")
• 17sec ("Best performance")

Yeah, that's an improvement, it's comparable to Hyper-V now, which should be, since it is using the same infrastructure. Key takeaway is that pure emulation is painfully slow when the CPU is throttled, so better plug in or run on the beefiest power profile, while WHPX acceleration definitely helps when power constrained - it actually makes the thing usable. It's also reassuring to see that the power profiles slider in Windows actually does something and there aren't any surprises, like "Better performance" performing better than "Best performance" and so on.

These tutorials are definitely doable on Windows when using WSL2. Instead of installing QEMU in WSL2, install it on the Windows host directly. Afterwards, just add the QEMU install folder to PATH on Windows, and then when invoking from the bash prompt in WSL2, instead of qemu-system-x86_64, use qemu-system-x86_64.exe - this will launch QEMU in Windows from the WSL2 prompt. I stored all the images/experiments in /mnt/c/... under WSL2, so in the Windows visible storage. I doesn't work when the files are hosted in the WSL2 virtual disk, yielding an error like:

**
ERROR:../../../block.c:1699:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment))
Bail out! ERROR:../../../block.c:1699:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment))

Thanks for the links and view on the subject, it definitely paved the way for better workflows for me.