ipaqmaster/vfio

Easy to accidentally near-deadlock system

zorbathut opened this issue · 3 comments

This is sort of an addendum to #14.

On my first run, it started qemu and then nearly deadlocked my system while running fans at full blast. I'm not totally sure why. My theory is that it was trying to use all the CPUs, and the EFI environment that it dropped into was busywaiting. Which meant it was busywaiting on all the CPUs and starving the host OS of cycles. I was able to very slowly open a commandline and sudo killall qemu-system-x86_64 but that was not exactly the best initial experience. I added a specific set of CPU pins next time and haven't had the problem since, but I also haven't been, y'know, interested in repeating the experience.

Maybe the default settings shouldn't assign all the CPUs, just to avoid something like that? Something like cpus / 2, to parallel the RAM default.

This is certainly a known behavior of qemu. I've also noticed that Windows 10 and 11 will use 100% CPU on ALL CORES when they run into trouble which can really lock up a host (Or slow it down to a few operations per second the guest does this).

The only solution I can think of on the current release is to use -pinvcpus to give the guest some specific host cpu threads to work on rather than letting the default "Give all cores" behavior take reign.

I could consider adding something like a a generic -vcpus/-cpus xx flag to take a number of guest vcpus without pinning, but in my case I just end up using -pinvcpus instead to achieve the same effect.

I do like the idea of the default using cpus/2 just like the ram does. That's something which would be easily implemented as well.

image
Managed to tweak it and a VM made with ~/vfio/main -m 8g -iso /data/ISOs/archlinux-2023.01.01-x86_64.iso -run seems to be taking only half my host's cores and threads now. I'll commit this and if it goes well it'll be in a tag sooner than later.

Updated the script output for this too:

-pinvcpus not specified, guest will execute on half the host's CPU threads total (No pinning): 6 (12/2) giving the guest 12 (24/2) threads.

Committed as 075055d thanks for bringing this up!