<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On 15 Nov 2018, at 06:59, A Z <<a href="mailto:adam@zegelin.com" class="">adam@zegelin.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">
<div class="">This is an issue that involves a combination of different software
packages, so my apologies in advance if this is the wrong list to post
on.</div><div class=""><br class=""></div><div class="">I'm experiencing terrible boot times when I
assign a large amount of RAM to a VM when used in combination with
VIFO/PCI-passthrough.</div><div class=""><br class=""></div><div class="">On a VM with a
Nvidia GTX 970 + USB controller
and 24GiB of RAM assigned, the time to the TianoCore splash screen is ~5
minutes. It's then ~30 seconds before Windows 10 begins to boot
(spinning dots). During this time, the QEMU CPU core threads are 100%
busy.</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div>This sounds quite like a problem I used to have in the past with certain versions of OVMF and the Linux kernel. If I remember correctly, some memory ranges would get marked as non-cacheable, which resulted in the terrible slowdown you describe. The resolution back then was to stick to older versions of both the firmware and the kernel.</div><div><br class=""></div><div>I still keep around an older version of OVMF that I used until recently - edk2.git-ovmf-x64-0-20160714.b1992.gfc3005.noarch.rpm. You could download the RPM here and try if it works for you:</div><div><br class=""></div><div><a href="https://exa.flopser.de/s/z3cjqFUlZ2gBPCy" class="">https://exa.flopser.de/s/z3cjqFUlZ2gBPCy</a></div><div><br class=""></div><div>Recent QEMU versions started complaining about firmware incompatibilities, so I tried the latest RPM from Kraxel (<a href="https://www.kraxel.org/repos/jenkins/edk2/" class="">https://www.kraxel.org/repos/jenkins/edk2/</a>) and it works just fine. The host system is Arch Linux with the latest Arch kernel and QEMU.</div><div><br class=""></div><div>Cheers,</div><div>Hristo</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">According to `perf`, the QMU CPU core
threads are spending most of their time waiting on a spinlock over
kvm->mmu_lock that's created by kvm_zap_gfn_range.</div><div class=""><br class=""></div><div class="">I'm fairly certain that ~1 year ago (if not longer) the same configuration didn't take this long to boot.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Adam</div>
</div>
_______________________________________________<br class="">vfio-users mailing list<br class=""><a href="mailto:vfio-users@redhat.com" class="">vfio-users@redhat.com</a><br class="">https://www.redhat.com/mailman/listinfo/vfio-users</div></blockquote></div></body></html>