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
