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

[Hristo Iliev]

Hi,

I'm running a Win10 VM on a X99 host with i7-5820k and up-to-date Arch. OVMF is from a manually extracted RPM from the Fedora repository (https://www.kraxel.org/repos/jenkins/edk2/ (https://www.kraxel.org/repos/jenkins/edk2/)). The VM boots fast..

I'm also passing through a GTX 970, though I only give the VM 12 GiB of RAM and 3 cores + hyperthreads. If not for OVMF and the amount of cores and RAM, then the main difference I could think of is that your VM's machine is q35 while mine is pc-i440fx-2.5. Could you try a i440fx configuration too? Try also with an older version of OVFM. Mine is from 18th July 2016. I stopped updating it once everything was running smoothly. There used to be a problem with a wide range of Linux kernels that would result in extremely slow boot for VMs with more than 2 GiB of memory, but that was resolved a long time ago and recent Arch kernels work out of the box.

Cheers,
Hristo

24. Juli 2017 18:19, "John Koelndorfer"  schrieb:
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 (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/72db4e0c/attachment.htm>