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.
Regards,
Martin