UTM
UTM copied to clipboard
x86 emulation in UTM runs significantly more slowly than running `qemu-system-x86_64` binary directly
BEFORE SUBMITTING YOUR ISSUE, PLEASE LOOK AT THE PINNED ISSUES AND USE THE SEARCH FUNCTION TO MAKE SURE IT IS NOT ALREADY REPORTED. ALWAYS COMMENT ON AN EXISTING ISSUE INSTEAD OF MAKING A NEW ONE.
Describe the issue
I am noticing significant slowdowns when running a Windows XP VM in UTM vs. running it directly via ./qemu-system-x86_64 -accel tcg -hda /path/to/winxp.qcow2 on qemu from homebrew. This seems to occur regardless of whether I run UTM/QEMU on M1 or on Intel. Some numbers I am seeing:
Core i9 MacBook Pro, qemu-system-x86_64, -accel tcg: ~39s to the desktop
Core i9 MacBook Pro, UTM, -accel tcg: ~6.5 min to the desktop
Core i9 MacBook Pro, qemu-system-x86_64, -accel hvf: ~2 min to the desktop (why this is slower than TCG is a question for a different report)
Core i9 MacBook Pro, UTM, -accel hvf: ~8 minutes to the desktop
M1 Max MacBook Pro, qemu-system-x86_64, -accel tcg: ~21s to the desktop
M1 Max MacBook Pro, UTM, -accel tcg: ~1 min to the desktop
It is possible that this is caused by one of the settings that UTM sets. Unfortunately, it is hard for me to test this directly since many of the options exported by the "Export QEMU Command" button do not seem to be valid options on qemu from homebrew.
Configuration
- UTM Version: 4.2.5 stable and 4.3.1 beta (tested with both)
- macOS Version: Ventura 13.4.1 (c)
- Mac Chip (Intel, M1, ...): Core i9, M1 Max (tested with both)
click and choose
Reveal in Finder. Attach the report here.
Debug log
Debug log appears empty when I export it.
Upload VM
config.plist.zip
Can you try with -vga qxl -device ac97 -netdev user,id=mynet0 -device rtl8139,netdev=mynet0? Just to have a similar configuration? Also on UTM change the network mode to Emulated to get a similar result.
That results in the following error message:
qemu-system-x86_64: QXL VGA not available
edit: leaving out the -vga qxl argument, timings are unchanged, other than the following errors occurring repeatedly in the console:
audio: Could not create a backend for voice `ac97.pi'
audio: Could not create a backend for voice `ac97.mc'
Changing UTM's network to Emulated didn't seem to make an appreciable difference either; it's still significantly slower than running QEMU directly. Unfortunately I'm traveling at the moment and don't have access to my Intel machine, but on the M1 Max today it's 24s for qemu, 51s for UTM.
Change UTM’s video emulated card to VGA to match QEMU maybe?
Set the video to VGA and ran the tests again. Ran it twice on each to see if any caching was influencing the results.
UTM 4.2.5: 54s, 54s UTM 4.3.1 beta: 50s, 46s qemu-system-x86_64: 28s, 26s
Looks like the VGA change may have helped a bit (although it's close enough to be unclear whether it's placebo effect), but it doesn't seem to be all the way there. Again this is on M1 Max, as I won't be able to test it on the Intel machine until I'm back home.
Can you list your full QEMU arguments just in case others want to try to reproduce?
For the last test, I used:
qemu-system-x86_64 -accel tcg -hda /Users/_redacted_/Library/Containers/com.utmapp.UTM/Data/Documents/Windows\ XP.utm/Data/disk-0.qcow2 -device ac97 -netdev user,id=mynet0 -device rtl8139,netdev=mynet0
The -device ac97 -netdev etc... was my attempt to bring this closer to what UTM is doing by copying the arguments that didn't cause an error.
Really interesting thread. I can't find arguments based on UTM command to launch directly my Win10 x86 UTM VM... To many errors (spice-vmc, spiceport, spice (audiodev), vmnet-shared) when copying UTM arguments and pasting to qemu-system-x86_64 in shell... When the VM seems to boot : Guest has not initialized the display (yet)...
Has anyone checked in on why x86 machines run faster when force PS/2 is enabled?
This series may be of interest: https://patchew.org/QEMU/[email protected]/
Just to clarify, you can't use HVF acceleration on Apple Silicon with i386/x86_64 guests, right?
The (hopefully) final version of the series has just been posted at https://patchew.org/QEMU/[email protected]/