On Wed, Aug 11, 2021 at 9:53 AM Daniel P. Berrangé <berrange(a)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(a)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.
--
Eduardo