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

Re: qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

On Tue, 2020-08-18 at 15:15 -0600, Jim Fehlig wrote:
> On 8/5/20 2:19 AM, Andrea Bolognani wrote:
> > 
> > I guess we need to start checking the modules directory in addition
> > to the main QEMU binary, and regenerate capabilities every time its
> > contents change.
> We recently received reports of this issue on Tumbleweed, which just
> got the 
> modularized qemu 5.1
> https://bugzilla.opensuse.org/show_bug.cgi?id=1175320
> Mark, are you working on a patch to invalidate the cache on changes
> to the qemu 
> modules directory? I suppose it needs to be handled similar to the
> qemu 
> binaries. E.g. when building the cache include a list of all qemu
> modules found. 
> When validating the cache see if any modules have disappeared, if any
> have been 
> added, and if the ctime of any have changed. Yikes, sounds a little
> more complex 
> than the binaries :-).

I'd like to question whether this effort is justified for an
optimization that matters only at libvirtd startup time, and even there
saves no more than a few seconds. 

I propose to simply disable the caching of qemu capabilities (or
provide a build-time option to do so). Optimizations that produce wrong
results should be avoided.

> I wonder if it is possible to use inotify to receive notification of
> changes to 
> the modules directory?

That would certainly be possible, but it'd be a new feature (getting
aware of qemu capability changes during runtime), while we're currently
discussing an existing feature (getting qemu capabilities on startup)
which is broken. I believe these issues should be discussed separately.


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