[libvirt PATCH 0/3] Invalidate the cpu flags cache on changes of kernel command line

Daniel P. Berrangé berrange at redhat.com
Fri Aug 6 17:12:21 UTC 2021


On Fri, Aug 06, 2021 at 05:07:45PM +0200, Jiri Denemark wrote:
> On Thu, Aug 05, 2021 at 14:50:51 +0100, Daniel P. Berrangé wrote:
> > On Thu, Aug 05, 2021 at 03:36:37PM +0200, Tim Wiederhake wrote:
> > > The kernel command line can contain settings affecting the availability
> > > of cpu features, eg. "tsx=on". This series adds the kernel command line
> > > to the cpu flags cache and declares the cache invalid if the current
> > > kernel command line differs.
> > 
> > Multiple things can change the CPU features. kernel version,
> > microcode version, bios settings change, kernel command line. We've
> > been playing whack-a-mole in cache invalidation for ages adding ever
> > more criteria for things which have side effects on CPU features
> > available.
> > 
> > Running the CPUID instruction is cheap. Could we directly query the
> > set of host CPUID leaves we care about, and compare that, and
> > potentially even get rid of some of the other checks we have ?
> 
> I guess it could help in some cases, but we wouldn't be able to drop
> some of the existing checks anyway. Because the settings usually do not
> result in the CPU dropping a particular bit from CPUID, the feature just
> becomes unusable by reporting a failure when used. So the settings would
> only be reflected in what features QEMU can enable on the host. Although
> checking CPUID might be enough for TSX, checking the command line is
> helpful in other cases.

Would that be reflected by the answer to KVM_GET_SUPPORTED_CPUID
which is the intersection of physical CPUID and what KVM is actally
willing to enable ?  That ioctl would be cheap too.


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 :|




More information about the libvir-list mailing list