qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Boris Fiuczynski" <fiuczy@linux.ibm.com>,
	"Daniel P. Berrange" <berrange@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>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [PATCH 1/1] hw/s390x: modularize virtio-gpu-ccw
Date: Fri, 19 Feb 2021 03:52:06 +0100	[thread overview]
Message-ID: <20210219035206.730f145e.pasic@linux.ibm.com> (raw)
In-Reply-To: <20210218133820.cflf455nj44mxzja@sirius.home.kraxel.org>

On Thu, 18 Feb 2021 14:38:20 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> > > The explanation is simple. Unlike most devices, the ccw devices aren't
> > > portable. In particular both css.c and css.h includes "cpu.h", and
> > > virtio-ccw-gpu.c includes "qemu/osdep.h". Furthermore osdep.h contains:
> > > #ifdef NEED_CPU_H
> > > #include CONFIG_TARGET
> > > #else
> > > #include "exec/poison.h"
> > > #endif
> > > so if we don't have NEED_CPU_H, among others CONFIG_KVM is poisoned, and
> > > CONFIG_KVM is used in "css.h". Frankly, I can't tell under what circumstances
> > > does css need "cpu.h".   
> > 
> > s390_crw_mchk() and s390_io_interrupt() are in cpu.h. Nowadays, they
> > use the flic to inject interrupts; but their earlier implementations
> > had a dummy cpu state.
> > 
> > I'm wondering whether s390_flic.h is a better place for functions
> > injecting floating interrupts, now that we don't have the non-flic
> > support anymore.  
> 
> Sounds like the easiest way forward.  Alternatively add support for
> target-specific modules (which we don't really have right now).

Thanks Gerd! 

Now I realize what do you mean by support for target-specific modules.
I'm mostly concerned with the s390x targets and I didn't have a good
enough understanding of this. I didn't realize the modules are shared
for all targets, that's why I've tried to build it only for s390x
targets.

I don't see way around target-specific modules. With the modifications
suggested by Thomas and Connie, I was able to get the new module to
compile regardless of the target, but that "fixes" s390x at the expense
of breaking all the other targets. For example:
./qemu-system-x86_64 -device help
Type 'virtio-gpu-ccw' is missing its parent 'virtio-ccw-device'
Aborted
because each target specific qemu will try to load my module. For s390x
it will work as expected, for everybody else not at all.

Making the list of modules in module.c depend on the target, i.e.
something like
     { "vhost-user-gpu-pci",    "hw-", "display-virtio-gpu-pci" }
+#ifdef TARGET_S390X
     { "virtio-gpu-ccw",        "hw-", "s390x-virtio-gpu-ccw"   },
+#endif
doesn't look viable either.

Since you are the author of 28457744c3 ("module: qom module support") and
7b0de5b796 ("virtio-gpu: build modular"), before I start working on
target-specific modules I would like to ask you, what is in your opinion
the best way to implement these?

Regards,
Halil


  parent reply	other threads:[~2021-02-19  2:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18  2:22 [PATCH 1/1] hw/s390x: modularize virtio-gpu-ccw Halil Pasic
2021-02-18  9:23 ` Thomas Huth
2021-02-18 10:34   ` Halil Pasic
2021-02-18 12:56     ` Cornelia Huck
2021-02-18 13:38       ` Gerd Hoffmann
2021-02-18 18:17         ` Halil Pasic
2021-02-19  8:34           ` Gerd Hoffmann
2021-02-19  2:52         ` Halil Pasic [this message]
2021-02-19  8:45           ` Gerd Hoffmann
2021-02-19  9:42             ` Halil Pasic
2021-02-19 13:58               ` Gerd Hoffmann
2021-02-18 14:44     ` Thomas Huth
2021-02-18 18:26       ` 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=20210219035206.730f145e.pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=brogers@suse.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).