Re: [PATCH v3 1/1] hw/s390x: modularize virtio-gpu-ccw

[Gerd Hoffmann]

On Fri, Mar 05, 2021 at 04:46:03PM -0500, Eduardo Habkost wrote:
> On Tue, Mar 02, 2021 at 06:35:44PM +0100, Halil Pasic wrote:
> > Since the virtio-gpu-ccw device depends on the hw-display-virtio-gpu
> > module, which provides the type virtio-gpu-device, packaging the
> > hw-display-virtio-gpu module as a separate package that may or may not
> > be installed along with the qemu package leads to problems. Namely if
> > the hw-display-virtio-gpu is absent, qemu continues to advertise
> > virtio-gpu-ccw, but it aborts not only when one attempts using
> > virtio-gpu-ccw, but also when libvirtd's capability probing tries
> > to instantiate the type to introspect it.
> > 
> > Let us thus introduce a module named hw-s390x-virtio-gpu-ccw that
> > is going to provide the virtio-gpu-ccw device. The hw-s390x prefix
> > was chosen because it is not a portable device. Because registering
> > virtio-gpu-ccw would make non-s390x emulator fail due to a missing
> > parent type, if built as a module, before registering it, we check
> > if the ancestor types are already registered.
> 
> I don't understand what makes it necessary to make the
> type_register() call conditional.  Calling type_register() before
> the parent types are registered is perfectly valid.

Well, yes, in a non-modular world this will work perfectly fine.  We
only compile objects actually supported into the system emulator.

With modular builds we have the situation that we have shared modules
which may or may not work in specific system emulators, for example
hw-display-virtio-gpu-pci.so or the ccw module added by this patch,
because the given system emulator doesn't provide the needed support.
We have some which don't support pci (avr for example).  Likewise ccw
is supported by s390x only.

When loading the ccw module into a non-s390x the object initialization
fails due to the missing parent object and we run into an assert.

Loading a pci module into a non-pci system emulator would have an
simliar effect, except that those modules don't load in the first
place due to missing symbol references for pci_* functions.

So we are looking for some way to deal with the situation, i.e.
avoid failing type initialization (we could also catch type
initialitation failues, but there are *lots* if places in qemu ...).
So not registering a type where we know it will fail is the idea here,
taking advantage of the fact that in case of modules the types are
actually loaded and initialized in order, so if the parent type isn't
present at registration time it wouldn't show up later.

Hmm, while thinking about it, a completely different idea:  Maybe add
explicit symbol references instead?  i.e. add "have_$feature = 1"
variables (either unconditionally, or only for the cases where we don't
have symbol references anyway), then reference them in modules needing
the feature like this:

        if (have_bus_ccw) {
                type_register(&type_virtio_gpu_ccw);
        }

take care,
  Gerd