Re: [libvirt] [PATCH] qemu: Refresh caps cache after booting a different kernel

On 22.01.2018 15:36, Daniel P. Berrange wrote: > On Mon, Jan 22, 2018 at 01:31:21PM +0100, Jiri Denemark wrote: >> On Mon, Jan 22, 2018 at 10:57:57 +0000, Daniel P. Berrange wrote: >>> On Mon, Jan 22, 2018 at 11:46:14AM +0100, Jiri Denemark wrote: >>>> Whenever a different kernel is booted, some capabilities related to KVM >>>> (such as CPUID bits) may change. We need to refresh the cache to see the >>>> changes. >>>> >>>> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com&gt; >>>> --- >>>> >>>> Notes: >>>> The capabilities may also change if a parameter passed to a kvm module >>>> changes (kvm_intel.nested is a good example) so this is not a complete >>>> solution, but we're hopefully getting closer to it :-) >>> >>> You mean getting closer to a situation where we are effectively storing the >>> cache on tmpfs, because we invalidate it on every reboot ! >> >> Well, that's a possible result, yes. Although it's both incomplete and >> invalidating the cache too often at the same time. It's possible we >> won't be able to come up with anything more clever anyway. >> >>> I think sometime soon we're going to need to consider if our cache invalidation >>> approach is fundamentally broken. We have a huge amount of stuff we query from >>> QEMU, but only a tiny amount is dependant on host kernel / microcode / kvm mod >>> options. Should we go back to invalidating only when libvirt/qemu binary changes >>> but then do partial invalidation of specific data items for kernel/microcode >>> changes. >> >> On the other hand, while we have QEMU running, probing for all >> capabilities vs just a limited set which depend on the host shouldn't be >> a big difference. I haven't actually measured it though. However, we >> only invalidate the cache more often for KVM, which makes it pretty >> limited already since we only invalidate the capabilities for a single >> binary. > > Oh true, I didn't notice you'd only done invalidation for the KVM code > path. That should avoid the major pain that GNOME Boxes saw where we > spend ages probing 20 QEMU binaries on every startup > Hi. Hope this topic is not too old... If this is what qemu caps cache for - dealing with a lot of binaries we could disable cache for kvm only and solve issues with kvm_intel.nested.