On Fri, Aug 06, 2021 at 18:12:21 +0100, Daniel P. Berrangé wrote:
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.
I don't know, to be honest. I guess it should work unless QEMU does some
additional processing/filtering of the results it gets from KVM.
Eduardo, do you know if KVM_GET_SUPPORTED_CPUID would be sufficient to
check any configuration changes (bios settings, kernel command line,
module options, ...) that affect usable CPU features?
Jirka