From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QW29P-0006qz-KW for qemu-devel@nongnu.org; Mon, 13 Jun 2011 04:05:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QW29O-00026N-Gs for qemu-devel@nongnu.org; Mon, 13 Jun 2011 04:05:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QW29O-00026I-6K for qemu-devel@nongnu.org; Mon, 13 Jun 2011 04:05:34 -0400 Message-ID: <4DF5C4BB.8000908@redhat.com> Date: Mon, 13 Jun 2011 11:05:15 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1307532813-27175-1-git-send-email-peter.maydell@linaro.org> <4DEF6B2B.7090305@siemens.com> <4DF0FCDA.5070804@siemens.com> <4DF21334.2070204@us.ibm.com> <4DF23BB7.9050606@us.ibm.com> <4DF4F371.90003@redhat.com> <4DF511B6.5000005@us.ibm.com> In-Reply-To: <4DF511B6.5000005@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , =?ISO-8859-1?Q?Juha_Riihim=E4ki?= , "patches@linaro.org" , Jan Kiszka , "qemu-devel@nongnu.org" , Markus Armbruster , Paul Brook On 06/12/2011 10:21 PM, Anthony Liguori wrote: >> >>> It's perfectly fine to have a type called PCIBus that I440FX extends, >>> but qdev shouldn't have explicit knowledge of something called a "bus" >>> IMHO. Doing this forces a limited mechanism of connecting devices >>> because it creates an artificial tree (by implying a parent/child >>> relationship). It makes composition difficult if not impossible. >> >> I think qdev buses are useful as long as they don't enforce their >> interfaces. That is, a qdev that is a child of a qbus has access to the >> qbus's interfaces, but also access to other stuff. > > > I see two independent data structures. The first is the > "instantiation tree". > > The instantiation tree may look like this: > > +-- i440fx > | | > | +-- PIIX3 > | | | > | | +-- mc146818a > | | +-- uart > | | +-- DMA > | | +-- keyboard controller > | | +-- (remaining platform ISA devices > | | > | +-- UHCI USB controller > | +-- IDE controller > | > +-- e1000 > +-- cirrus-vga > +-- virtio-balloon-pci > +-- IDE disk0 > > Instantiating i440fx makes a bunch of default stuff. This is > composition. Everything else requires explicit instantiation. This > is, strictly speaking, the parent/child relationships. If you destroy > i440fx, all of it's children have to also go away (by definition). > Nothing about bus relationship is implied here. Even if i440fx > exposes a PCI bus, the PIIX3 is a child of i440fx even though e1000 is > not (even if they're both PCI devices). I bus/device relationship is not imposed, but may hold for some of the devices (but not others). Another example of aggregation is PCI slots and functions. A PCI device is composed of multiple functions that can be hotplugged as one, and share parts of the address. But there is no "slot/function bus" involved. > > That said, there absolutely should be the following paths: > > /i440fx/IDE controller/primary/master -> IDE disk0 > /i440fx/slot3 -> cirrus-vga > > The expression of bus should just be a bidirectional path (when that > makes sense). IOW: > > /i440fx/slot3 -> cirrus-vga > /cirrus-vga/bus -> i440fx > > There, of course, can be all sorts of crazy paths through the graph. > The following should be valid: > > /i440fx/slot2 -> IDE controller > /cirrus-vga/bus/slot2/primary/master > > But separating out hw paths from instantiation tree has some nice > characteristics. The instantiation tree is the obvious place to > implement live migration whereas reset would probably walk device paths. Agreed; and it's quite obvious as the bus has a RESET line but no relationship to live migration. -- error compiling committee.c: too many arguments to function