From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWBKK-0006NW-T0 for qemu-devel@nongnu.org; Mon, 13 Jun 2011 13:53:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWBKJ-0006bk-Nh for qemu-devel@nongnu.org; Mon, 13 Jun 2011 13:53:28 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:47907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWBKJ-0006bd-LB for qemu-devel@nongnu.org; Mon, 13 Jun 2011 13:53:27 -0400 Received: by gxk26 with SMTP id 26so3910085gxk.4 for ; Mon, 13 Jun 2011 10:53:25 -0700 (PDT) Message-ID: <4DF64E8F.1020303@codemonkey.ws> Date: Mon, 13 Jun 2011 12:53:19 -0500 From: Anthony Liguori 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> <4DF5C4BB.8000908@redhat.com> In-Reply-To: <4DF5C4BB.8000908@redhat.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: Avi Kivity Cc: Peter Maydell , =?ISO-8859-1?Q?Juha_Riihi?= =?ISO-8859-1?Q?m=E4ki?= , "patches@linaro.org" , Jan Kiszka , Markus Armbruster , "qemu-devel@nongnu.org" , Paul Brook On 06/13/2011 03:05 AM, Avi Kivity wrote: > 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. Correct. This also hints at how hot plug could work. If devices had properties of type socket that you could connect devices too, a device could conceivably lock the socket after the device is realized (becomes guest visible). Sockets that aren't locked after realize are hot pluggable. Hot plugging simply becomes making a connection post realize. An address is implied by the property path. This gives you a way to allow PCI devices to be plugged in sockets (including multifunction devices) while not allowing individual functions to be hot plugged. Regards, Anthony Liguori Regards, Anthony Liguori