Re: [libvirt PATCH 0/3] Invalidate the cpu flags cache on changes of kernel command line

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux