On Wed, Aug 11, 2021 at 4:43 AM Jiri Denemark <jdenemar@xxxxxxxxxx> wrote: > > 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? GET_SUPPORTED_CPUID is supposed to be enough to cover all kernel-side factors (including host CPUID flags, kernel and module options, bios settings). However, I would call KVM_GET_MSRS (the system ioctl, not the VCPU ioctl) to be extra safe. Some features are available only if KVM supports MSRs required for them, and some features are exposed to guests through bits in some MSRs. That would mean KVM_GET_SUPPORTED_CPUID + KVM_GET_MSRS + QEMU binary identifier (hash or date/time?) should be sufficient today. The problem here is the word "today": we never know what kind of extra KVM capabilities new features might require. Wouldn't it be easier to simply invalidate the cache every time libvirtd is restarted? If libvirtd keeps /dev/kvm open all the time, this would also cover features affected by KVM module reloads. -- Eduardo
