From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV1Bj-0007OU-Hf for qemu-devel@nongnu.org; Fri, 10 Jun 2011 08:51:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QV1Bh-0003xF-Sa for qemu-devel@nongnu.org; Fri, 10 Jun 2011 08:51:47 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:48850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV1Bh-0003x5-94 for qemu-devel@nongnu.org; Fri, 10 Jun 2011 08:51:45 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5ACiEAo010574 for ; Fri, 10 Jun 2011 06:44:14 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5ACp4Va276080 for ; Fri, 10 Jun 2011 06:51:08 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5ACp3Be016238 for ; Fri, 10 Jun 2011 06:51:04 -0600 Message-ID: <4DF21334.2070204@us.ibm.com> Date: Fri, 10 Jun 2011 07:51:00 -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> In-Reply-To: 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: Markus Armbruster Cc: Peter Maydell , =?ISO-8859-1?Q?Juha_Riihim=E4ki?= , "patches@linaro.org" , Jan Kiszka , "qemu-devel@nongnu.org" , Paul Brook On 06/10/2011 03:13 AM, Markus Armbruster wrote: > Jan Kiszka writes: >> Resource management, e.g. IRQs. That will be useful for other types of >> buses as well. > > A device should be able to say "I need to be connected to an IRQ line". > Feels generic to me. More specifically, a device has input IRQs. A device has no idea what number the IRQ is tied to. Devices may also have output IRQs. At the qdev layer, we should be able to connect an arbitrary output IRQ to an arbitrary input IRQ. So the crux of the problem is that: -device isa-serial,id=serial,irq=3 Is very wrong. It ought to look something more like -device piix3,id=piix3 -device isa-serial,id=serial,irq=piix3.irq[3] IRQ forwarding becomes very easy in this model because your composite qdev device has a set of input IRQs and then routes the input IRQs to the appropriate input IRQs of the sub devices. The trouble is that I don't think we have a reasonable way to refer to properties of other devices and we don't have names for all devices. I think if we fix the later problem, the former problem becomes easier. > Connecting the two is configuration. Requires a suitable naming scheme > for IRQ lines. Naming might have to include bus-specific sugar for > user-friendliness. For instance, I'd rather express "isa-serial uses > ISA interrupt 4" as "irq=4" than as something like > "irq=PIIX3/isa.0:irq.4". That's just syntactic sugar. It can live at a higher level than the qdev API. > I doubt all resources are as generic as IRQ lines, but that's okay. They pretty much are. We're really just talking about referring to subcomponents of a device. That's what's lacking today. > Device component composition is not (yet?) covered by qdev. Of course > we compose anyway, in various ad hoc ways. Busses need to die. They can be replaced by having fixed "slots". For instance, if you had a way of having a PCIDevice * property, the I440FX could have 32 PCIDevice * properties. That's how you would add to a bus (and notice that it conveniently solves bus addressing in a robust fashion). Regards, Anthony Liguori > One way is to put the components' state structs into the device's state > struct, and define suitable wrappers. For instance, we have qdevs > "sysbus-fdc" and "isa-fdc". They both contain the FDC proper as a > component: FDCtrlSysBus and FDCtrlISABus contain a FDCtrl member. > Simple enough. > > A different way to adapt the same component to different buses can be > found in virtio: VirtIOPCIProxy and VirtIOS390Device both contain > pointers to VirtIODevice. I found that one quite awkward to work with. > > Yet another way can be found in usb-storage. usb-storage expands into > two qdevs connected by a qbus: it provides a SCSI bus, and automatically > creates a single scsi-disk on that bus. One of those tricks that look > cute initially, then create no end of trouble. > > I figure a "qdevy" composition mechanism would be useful. Needs > thought.