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

[Halil Pasic <pasic@linux.ibm.com>]

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

>   Hi,
> 
> > > 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.  

I believe the easiest way forward is what I propose in this patch. Does
this mean, that the code I propose here is not viable? If yes, why?

I'm not against cleaning up the includes for virtio-ccw devices, but I
tend to see that as a separate, less pressing issue.

> Alternatively add support for
> target-specific modules (which we don't really have right now).

I think a target-specific module is what I did in this patch.
Furthermore, I think any virtio-ccw device that is about to be built as
a module, must be built as a target-specific module. If the realized
(guest) architecture is not s390x, then there are no s390 IO instructions
and ccw won't fly. Yes, in theory other architectures could introduce the
exact same stuff, but I don't see that happening.

Even if I were to move the two functions like Connie suggests, I don't
see a way around making virtio-9p-ccw target specific.

Regards,
Halil