From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: "armbru@redhat.com" <armbru@redhat.com>,
"mdroth@linux.vnet.ibm.com" <mdroth@linux.vnet.ibm.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"jfrei@linux.vnet.ibm.com" <jfrei@linux.vnet.ibm.com>,
"Xu Wang" <gesaint@linux.vnet.ibm.com>,
"lcapitulino@redhat.com" <lcapitulino@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 1/6] s390x/virtio-ccw: enable has_dynamic_sysbus
Date: Mon, 27 Apr 2015 18:56:51 +0200 [thread overview]
Message-ID: <20150427185651.3aaa3ae7.cornelia.huck@de.ibm.com> (raw)
In-Reply-To: <553E559D.5030905@suse.de>
On Mon, 27 Apr 2015 17:28:29 +0200
Alexander Graf <agraf@suse.de> wrote:
> On 04/27/2015 04:19 PM, Cornelia Huck wrote:
> > On Mon, 27 Apr 2015 15:57:04 +0200
> > Alexander Graf <agraf@suse.de> wrote:
> >
> >> On 04/24/2015 11:07 AM, Cornelia Huck wrote:
> >>> On Wed, 22 Apr 2015 14:21:36 +0200
> >>> Alexander Graf <agraf@suse.de> wrote:
> >>>
> >>>>> Am 22.04.2015 um 13:40 schrieb Cornelia Huck <cornelia.huck@de.ibm.com>:
> >>>>>
> >>>>> On Wed, 22 Apr 2015 11:14:40 +0200
> >>>>> Alexander Graf <agraf@suse.de> wrote:
> >>>>>
> >>>>>>> On 04/22/2015 10:25 AM, Cornelia Huck wrote:
> >>>>>>> On Tue, 21 Apr 2015 21:06:42 +0200
> >>>>>>> Alexander Graf <agraf@suse.de> wrote:
> >>>>>>>
> >>>>>>>>> On 04/17/2015 09:52 AM, Cornelia Huck wrote:
> >>>>>>>>> From: Xu Wang <gesaint@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.
next prev parent reply other threads:[~2015-04-27 16:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 7:52 [Qemu-devel] [PATCH 0/6] s390x: support diag288 watchdog Cornelia Huck
2015-04-17 7:52 ` [Qemu-devel] [PATCH 1/6] s390x/virtio-ccw: enable has_dynamic_sysbus Cornelia Huck
2015-04-21 19:06 ` Alexander Graf
2015-04-22 8:25 ` Cornelia Huck
2015-04-22 9:14 ` Alexander Graf
2015-04-22 11:40 ` Cornelia Huck
2015-04-22 12:21 ` Alexander Graf
2015-04-24 9:07 ` Cornelia Huck
2015-04-27 13:57 ` Alexander Graf
2015-04-27 14:19 ` Cornelia Huck
2015-04-27 15:15 ` Andreas Färber
2015-04-27 17:02 ` Cornelia Huck
2015-04-27 15:28 ` Alexander Graf
2015-04-27 16:56 ` Cornelia Huck [this message]
2015-04-28 6:50 ` Markus Armbruster
2015-04-17 7:52 ` [Qemu-devel] [PATCH 2/6] watchdog: Add watchdog device diag288 to the sysbus Cornelia Huck
2015-04-29 12:43 ` Markus Armbruster
2015-04-29 14:58 ` Cornelia Huck
2015-05-08 9:16 ` Cornelia Huck
2015-04-17 7:52 ` [Qemu-devel] [PATCH 3/6] s390/kvm: diag288 instruction interception and handling Cornelia Huck
2015-04-21 19:09 ` Alexander Graf
2015-04-22 8:32 ` Cornelia Huck
2015-04-22 9:16 ` Alexander Graf
2015-04-22 11:37 ` Cornelia Huck
2015-04-17 7:52 ` [Qemu-devel] [PATCH 4/6] watchdog: Add migration support to diag288 watchdog device Cornelia Huck
2015-04-17 7:52 ` [Qemu-devel] [PATCH 5/6] nmi: Implement inject_nmi() for non-monitor context use Cornelia Huck
2015-04-17 7:52 ` [Qemu-devel] [PATCH 6/6] watchdog: Add new Virtual Watchdog action INJECT-NMI Cornelia Huck
2015-04-17 12:28 ` Eric Blake
2015-04-20 15:23 ` Cornelia Huck
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=20150427185651.3aaa3ae7.cornelia.huck@de.ibm.com \
--to=cornelia.huck@de.ibm.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=gesaint@linux.vnet.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=lcapitulino@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/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).