Re: [Qemu-devel] [PATCH 1/6] s390x/virtio-ccw: enable has_dynamic_sysbus

[Cornelia Huck]

On Mon, 27 Apr 2015 17:28:29 +0200
Alexander Graf <address@hidden> wrote:

> On 04/27/2015 04:19 PM, Cornelia Huck wrote:
> > On Mon, 27 Apr 2015 15:57:04 +0200
> > Alexander Graf <address@hidden> wrote:
> >
> >> On 04/24/2015 11:07 AM, Cornelia Huck wrote:
> >>> On Wed, 22 Apr 2015 14:21:36 +0200
> >>> Alexander Graf <address@hidden> wrote:
> >>>
> >>>>> Am 22.04.2015 um 13:40 schrieb Cornelia Huck <address@hidden>:
> >>>>>
> >>>>> On Wed, 22 Apr 2015 11:14:40 +0200
> >>>>> Alexander Graf <address@hidden> wrote:
> >>>>>
> >>>>>>> On 04/22/2015 10:25 AM, Cornelia Huck wrote:
> >>>>>>> On Tue, 21 Apr 2015 21:06:42 +0200
> >>>>>>> Alexander Graf <address@hidden> wrote:
> >>>>>>>
> >>>>>>>>> On 04/17/2015 09:52 AM, Cornelia Huck wrote:
> >>>>>>>>> From: Xu Wang <address@hidden>
> >>>>>>>>>
> >>>>>>>>> We have to enable this flag to support dynamically adding devices 
> >>>>>>>>> to the
> >>>>>>>>> sysbus. This change is needed for the the upcoming diag288 watchdog.
> >>>>>>>> s390 doesn't have a "sysbus" per se. Please create a new bus type.
> >>>>>>> So what's wrong with the sysbus? I don't see why we should be 
> >>>>>>> different
> >>>>>>> than everyone else.
> >>>>>> The idea behind sysbus is that you have MMIO, PIO and IRQ pins
> >>>>>> connecting to a PIC. It provides a lot of infrastructure for those
> >>>>>> interfaces. S390 doesn't use any of them and instead wants registration
> >>>>>> on "diag" interfaces for example which I'd put on the same layer as PIO
> >>>>>> or MMIO registration.
> >>>>> I don't think a "diag" bus makes sense.
> >>>> You don't need a bus necessarily, just a parent class.
> >>>>
> >>>>> The individual diagnoses are
> >>>>> way too heterogenous beyond the fact that they use the same base
> >>>>> instruction.
> >>>>>
> >>>>> So where's the proper place for "misc" devices? My impression was that
> >>>>> they can go on the sysbus.
> >>>>>
> >>>> If you really don't want to create your own class, how about you inherit 
> >>>> from the DeviceState class?
> >>> I tried that for the watchdog, and it certainly works, but some things
> >>> end up odd:
> >>>
> >>> - in 'info qtree', the watchdog device does not show up at all
> >> Please try "info qom-tree". Andreas also has a patch outstanding that
> >> shows properties along the way with a verbose switch.
> > While it does show up in info qom-tree, is hiding it from info qtree a
> > good idea? I'd think that it is still widely used.
> 
> It's not really about hiding it, but just about putting it at a 
> different location. S390 won't be the only target that slowly moves to 
> non-qdev'ed devices, so this is a problem that we'll need to solve 
> regardless.

I'm just a bit uncomfortable with devices not showing up in info qtree.
info qom-tree is still too new :)

> 
> >
> >>> - in the list of devices printed by "-device help", diag288 is now the
> >>>     only device without any bus
> >> But it's not attached to a bus, so that's reasonable, no?
> > Hm. Are there bus-less devices on other platforms?
> 
> IIUC Andreas wants to move CPUs to bus-less devices. I'm sure there are 
> more to come.
> 
> That said, if you feel more comfortable with a bus, just create an 
> artificial s390 bus for "s390 platform devices".

Might make sense for now. I'm not really sure where I'd want to plug in
the devices alternatively.

> 
> >
> >>> I would have thought that any device not attached to a specialized bus
> >>> should end up on the main system bus, which brings me back to adding it
> >>> as a sysbus device ;)
> >> Not really, sysbus is QEMU's wording for what Linux calls "platform
> >> bus". It's where devices go to that are attached to MMIO/PIO/IRQ lines
> >> via some fabric that we don't model.
> > But in practice sysbus seems to be more like a catch-all: On s390x,
> > there are already things like the flic, various sclp-related devices,
> > the virtio bridges or the ipl device sitting on the sysbus. Should they
> > really be thrown out from the sysbus and dangle as bus-less devices? I
> > think there is a case to be made for a catch-all bus, even if it is not
> > the sysbus.
> 
> The problem is that before QOM sysbus was the lowest common denominator 
> that we had. Now with QOM, we're only slowly starting to get the ability 
> to have devices that are not attached to a bus.
> 
> >
> >> The target for devices that are not the above we now have non-bus'ed
> >> devices.
> > I'm afraid I can't parse that sentence :)
> 
> FWIW you're supposed to use direct, non-bus'ed QOM devices for devices 
> that don't sit on a bus now. Before this was not possible, now it is :).
> 
> I don't feel incredibly strongly about this, but I just consider it 
> awkward to plug s390 specific devices into a bus that implements 
> everything s390 doesn't do :).

Let me see if an s390 platform bus does it for us. Machine options or
so don't look particulary attractive to me right now.