[libvirt PATCH 0/3] Invalidate the cpu flags cache on changes of kernel command line
ehabkost at redhat.com
Wed Aug 11 14:04:56 UTC 2021
On Wed, Aug 11, 2021 at 9:53 AM Daniel P. Berrangé <berrange at redhat.com> wrote:
> On Wed, Aug 11, 2021 at 09:46:17AM -0400, Eduardo Habkost wrote:
> > On Wed, Aug 11, 2021 at 9:42 AM Daniel P. Berrangé <berrange at redhat.com> wrote:
> > > On Wed, Aug 11, 2021 at 09:33:08AM -0400, Eduardo Habkost wrote:
> > > > 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.
> > >
> > > Invalidating the cache on every restart defeats the very purpose of
> > > having a cache in the first place. Probing for capabilities slows
> > > startup of the daemon and that is what required introduction of a
> > > cache.
> > Can't libvirtd query CPU capabilities only when clients ask for that
> > information the first time?
> Anything is technically possible, but that's a significant change from
> what we would do today. It would still need caching and an invalidation
> strategy, because we don't want such probing to be in the startup path
> of every VM spawned.
Welp. If the goal is a short-term solution to the game of
whack-a-mole, I'd say GET_SUPPORTED_CPUID + KVM_GET_MSRS would be a
good enough solution to avoid having to enumerate every factor that
affects availability of features on the KVM side.
More information about the libvir-list