Open CharlesJS opened 1 year ago
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/20230922140914.13906-1-phil@philjordan.eu/
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/20240605112556.43193-1-phil@philjordan.eu/
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 desktopM1 Max MacBook Pro,
qemu-system-x86_64
,-accel tcg
: ~21s to the desktop M1 Max MacBook Pro, UTM,-accel tcg
: ~1 min to the desktopIt 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
Reveal in Finder
. Attach the report here.Debug log
Debug log appears empty when I export it.
Upload VM
config.plist.zip