[vfio-users] Awful boot times, current OVMF to blame?

[John Koelndorfer]

Hey folks,

I've got a working GPU passthrough configuration with an Nvidia GTX 970 and
i7 5820k on an up-to-date Arch Linux system. I'm not using any special
packages, just the standard Linux kernel and qemu. The script I use for
launching is out there on GitHub:
https://github.com/jkoelndorfer/local-tools/blob/master/workstation/vfio/qemu-win10.
If you browse the vfio directory you'll see some other relevant
configuration bits.

I've got the setup in a good working state now, except for one thing that's
bothersome. It takes a _long_ time for the VM to boot. As far as I can
tell, the issue is linked to the OVMF firmware.

When I start the VM, it takes maybe 10-15 seconds for the GPU output to
display anything on the monitor. In fact, if I want to get into the EFI
setup I need to start mashing escape before anything even comes up. When I
do finally get something, the VM is stuck on the TianoCore logo for another
30 seconds to a minute (haven't timed it).

Additionally, all of the CPUs that are assigned to the VM are pegged at
near 100% until Windows finally starts to boot.

I've also noticed that boot times improve if I assign fewer cores or less
memory to the VM.

Lastly I'd add that I recently reinstalled Arch on this machine and I had a
working VFIO setup previously that did not experience this problem, though
I was using libvirt and Windows 8 in that scenario. I'm now using plain
qemu and Windows 10. Prior to the rebuild I hadn't used my Windows 8 VM in
month or two, so I suppose it's possible that a recent update is the cause
of this problem.

I tried ovmf-git from the AUR and that didn't seem to help. I checked dmesg
and journalctl and I didn't see anything telling in the logs that would
indicate a problem.

Anybody else encountered this problem and, if so, have you discovered a
solution?

Many thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20170724/16bf7b66/attachment.htm>