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

[Alexander Graf]

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.

> > > - 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".

> > > 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 :).


Alex