Re: [RFC QEMU PATCH] ui: Make the DisplayType enum entries conditional

[Thomas Huth]

On 09/06/2021 13.49, Gerd Hoffmann wrote:
> On Wed, Jun 09, 2021 at 12:29:58PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 09, 2021 at 01:24:05PM +0200, Gerd Hoffmann wrote:
> > > On Wed, Jun 09, 2021 at 12:02:40PM +0200, Thomas Huth wrote:
> > > > Libvirt's "domcapabilities" command has a way to state whether
> > > > certain graphic frontends are available in QEMU or not. Originally,
> > > > libvirt looked at the "--help" output of the QEMU binary to determine
> > > > whether SDL was available or not (by looking for the "-sdl" parameter
> > > > in the help text), but since libvirt stopped doing this analysis of
> > > > the help text, the detection of SDL is currently broken, see:
> > > >
> > > >   https://bugzilla.redhat.com/show_bug.cgi?id=1790902
> > > >
> > > > QEMU should provide a way via the QMP interface instead. The simplest
> > > > way, without introducing additional commands, is to make the DisplayType
> > > > enum entries conditional, so that the enum only contains the entries if
> > > > the corresponding CONFIG_xxx switches have been set.
> > >
> > > Hmm, that'll break for the "dnf remove qemu-ui-sdl" case ...
> >
> > Note tht libvirt invalidates its cache of QEMU capabilities when it
> > sees the /usr/lib64/qemu directory timestamp change. So it ought to
> > pick up changes caused by installing/removing QEMU modules, and apply
> > this to future queries for domcapabilities, or when starting future
> > QEMU guests.
>
> That'll work fine for modules implementing qom objects / devices,
> because the list of available objects changes accordingly and libvirt
> can see that.
>
> The #if CONFIG_SDL approach will not work because qemu will continue to
> report sdl as supported even when the sdl module is not installed any
> more.

I guess we'd need a separate QMP command to fix that, which tries to load 
the modules first when being called? Something similar to what is being done 
in qemu_display_help() ?
That's certainly doable, too, just a little bit more complex... do we want 
that? Or is the quick-n-easy way via the schema good enough for most use 
cases? (I'm not that familiar with "virsh domcapabilities" ... is there any 
real usage for the <graphics> section or is this rather cosmetical?)

 Thomas


PS: My CI runs with the patch just finished, and apparently I missed some 
#ifdefs in other parts of the code ... so I need to respin this patch 
anyway, no matter which direction we decide to go...