From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymjsn-00060o-3H for qemu-devel@nongnu.org; Mon, 27 Apr 2015 10:19:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ymjsj-0005GQ-OZ for qemu-devel@nongnu.org; Mon, 27 Apr 2015 10:19:37 -0400 Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:40296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymjsj-0005Ff-G6 for qemu-devel@nongnu.org; Mon, 27 Apr 2015 10:19:33 -0400 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 27 Apr 2015 15:19:32 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 512DA17D805F for ; Mon, 27 Apr 2015 15:20:11 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3REJUkE60489890 for ; Mon, 27 Apr 2015 14:19:30 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3REJTrT006102 for ; Mon, 27 Apr 2015 08:19:30 -0600 Date: Mon, 27 Apr 2015 16:19:26 +0200 From: Cornelia Huck Message-ID: <20150427161926.6bf5d203.cornelia.huck@de.ibm.com> In-Reply-To: <553E4030.7060509@suse.de> References: <1429257161-29597-1-git-send-email-cornelia.huck@de.ibm.com> <1429257161-29597-2-git-send-email-cornelia.huck@de.ibm.com> <55369FC2.1090508@suse.de> <20150422102501.406fc113.cornelia.huck@de.ibm.com> <55376680.3070601@suse.de> <20150422134053.262405e2.cornelia.huck@de.ibm.com> <0B8264E8-159A-4DCB-AEE2-28EBC4504B80@suse.de> <20150424110730.1e9bcc77.cornelia.huck@de.ibm.com> <553E4030.7060509@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/6] s390x/virtio-ccw: enable has_dynamic_sysbus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "armbru@redhat.com" , "mdroth@linux.vnet.ibm.com" , "qemu-devel@nongnu.org" , "borntraeger@de.ibm.com" , "jfrei@linux.vnet.ibm.com" , Xu Wang , "lcapitulino@redhat.com" , Andreas =?UTF-8?B?RsOkcmJlcg==?= On Mon, 27 Apr 2015 15:57:04 +0200 Alexander Graf wrote: > On 04/24/2015 11:07 AM, Cornelia Huck wrote: > > On Wed, 22 Apr 2015 14:21:36 +0200 > > Alexander Graf wrote: > > > >> > >>> Am 22.04.2015 um 13:40 schrieb Cornelia Huck : > >>> > >>> On Wed, 22 Apr 2015 11:14:40 +0200 > >>> Alexander Graf wrote: > >>> > >>>>> On 04/22/2015 10:25 AM, Cornelia Huck wrote: > >>>>> On Tue, 21 Apr 2015 21:06:42 +0200 > >>>>> Alexander Graf wrote: > >>>>> > >>>>>>> On 04/17/2015 09:52 AM, Cornelia Huck wrote: > >>>>>>> From: Xu Wang > >>>>>>> > >>>>>>> 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. > > > - 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? > > > 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 target for devices that are not the above we now have non-bus'ed > devices. I'm afraid I can't parse that sentence :)