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

[Daniel P. Berrange]

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 at redhat.com>
> > > ---
> > > 
> > > 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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|