All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Boris Fiuczynski" <fiuczy@linux.ibm.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, "Bruce Rogers" <brogers@suse.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [PATCH v3 1/1] hw/s390x: modularize virtio-gpu-ccw
Date: Tue, 9 Mar 2021 13:21:14 +0000	[thread overview]
Message-ID: <YEd2SnQkdtfhI4dL@redhat.com> (raw)
In-Reply-To: <20210309124512.6goag5jblcje3umk@sirius.home.kraxel.org>

On Tue, Mar 09, 2021 at 01:45:12PM +0100, Gerd Hoffmann wrote:
> 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.

We could solve this by having a different location for loading modules
for each target.

  *  /usr/$LIB/qemu/

    All the real .so's go in here as today

  *  /usr/$LIB/qemu/$TARGET

    Populated with symlinks to the .so's in the parent dir,
    but /only/ those which are valid for this $TARGET

Then change QEMU  to load from the second dir.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2021-03-09 13:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 17:35 [PATCH v3 1/1] hw/s390x: modularize virtio-gpu-ccw Halil Pasic
2021-03-05 11:25 ` Halil Pasic
2021-03-05 11:54 ` Cornelia Huck
2021-03-05 12:05   ` Halil Pasic
2021-03-05 21:46 ` Eduardo Habkost
2021-03-08 21:19   ` Halil Pasic
2021-03-09 12:45   ` Gerd Hoffmann
2021-03-09 13:21     ` Daniel P. Berrangé [this message]
2021-03-13  2:09       ` Halil Pasic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YEd2SnQkdtfhI4dL@redhat.com \
    --to=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=brogers@suse.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.