On Mon, 27 Apr 2015 17:28:29 +0200 Alexander Graf <ag...@suse.de> wrote:
> On 04/27/2015 04:19 PM, Cornelia Huck wrote: > > On Mon, 27 Apr 2015 15:57:04 +0200 > > Alexander Graf <ag...@suse.de> wrote: > > > >> On 04/24/2015 11:07 AM, Cornelia Huck wrote: > >>> On Wed, 22 Apr 2015 14:21:36 +0200 > >>> Alexander Graf <ag...@suse.de> wrote: > >>> > >>>>> Am 22.04.2015 um 13:40 schrieb Cornelia Huck <cornelia.h...@de.ibm.com>: > >>>>> > >>>>> On Wed, 22 Apr 2015 11:14:40 +0200 > >>>>> Alexander Graf <ag...@suse.de> wrote: > >>>>> > >>>>>>> On 04/22/2015 10:25 AM, Cornelia Huck wrote: > >>>>>>> On Tue, 21 Apr 2015 21:06:42 +0200 > >>>>>>> Alexander Graf <ag...@suse.de> wrote: > >>>>>>> > >>>>>>>>> On 04/17/2015 09:52 AM, Cornelia Huck wrote: > >>>>>>>>> From: Xu Wang <gesa...@linux.vnet.ibm.com> > >>>>>>>>> > >>>>>>>>> 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.
