qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Jim Fehlig]

On 8/5/20 2:19 AM, Andrea Bolognani wrote:
> On Wed, 2020-08-05 at 02:09 -0400, Mark Mielke wrote:
>> Hi all:
>>
>> In testing qemu-5.1rc2 on my Fedora 32 home system, I found that
>> the Fedora rawhide package has broken out both the QXL display
>> device and the USB redirect device into separate RPM modules:
>>
>> qemu-device-display-qxl.x86_64         2:5.1.0-0.1.rc2.fc32
>> qemu-device-usb-redirect.x86_64        2:5.1.0-0.1.rc2.fc32
>>
>> The upgrade from 5.0.0 to 5.1.0 does not treat these sub-packages
>> as mandatory packages, therefore a straight upgrade of packages
>> causes these domcapabilities to disappear.
>>
>> If the user tries to use libvirt after this, then existing domains
>> using QXL display device or USB redirect device will fail to start.
>> If the user then investigates and realizes that they now need to
>> install the above packages separately, they find that qemu-kvm
>> recognizes the modules right away, but libvirt does not. This looks
>> to be due to the libvirt domcapabilities cache?
> 
> 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 wonder if it is possible to use inotify to receive notification of changes to 
the modules directory? Checking the ctime of the directory would work if modules 
have been added or removed, but not for modules that get updated. Maybe it's not 
a problem if capabilities don't change on module updates, but I suspect that is 
not the case. It seems perfectly reasonable for an updated module to introduce a 
new capability.

Regards,
Jim