src/qemu/qemu_capabilities.c | 34 ++++++++++++++++++++++++++++++++-- src/qemu/qemu_capspriv.h | 3 ++- tests/qemucapsprobe.c | 2 +- 3 files changed, 35 insertions(+), 4 deletions(-)
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. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1953389. Tim Wiederhake (3): virQEMUCaps: Add kernel command line virQEMUCapsCachePriv: Add kernel command line qemu: Invalidate capabilities cache on kernel command line mismatch src/qemu/qemu_capabilities.c | 34 ++++++++++++++++++++++++++++++++-- src/qemu/qemu_capspriv.h | 3 ++- tests/qemucapsprobe.c | 2 +- 3 files changed, 35 insertions(+), 4 deletions(-) -- 2.31.1
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 ? 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 :|
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. I'm afraid the only 100% correct solution would be to stop caching CPU data at all and always probe QEMU (for host CPU model expansion only and drop all the cache if the set of features changes), but this might be quite expensive. On the other hand, we would need to do it only for KVM, which means a single (or two for 32b vs 64b) on a host.. Jirka
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 :|
© 2016 - 2024 Red Hat, Inc.