From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV3sZ-0000On-Kq for qemu-devel@nongnu.org; Fri, 10 Jun 2011 11:44:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QV3sX-0005OG-IE for qemu-devel@nongnu.org; Fri, 10 Jun 2011 11:44:11 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:35017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV3sX-0005O8-8E for qemu-devel@nongnu.org; Fri, 10 Jun 2011 11:44:09 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5AFWukO007717 for ; Fri, 10 Jun 2011 11:32:56 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5AFi6ih1413274 for ; Fri, 10 Jun 2011 11:44:07 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5AFhufL012607 for ; Fri, 10 Jun 2011 12:43:57 -0300 Message-ID: <4DF23BB7.9050606@us.ibm.com> Date: Fri, 10 Jun 2011 10:43:51 -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> 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_Riihi?= =?ISO-8859-1?Q?m=E4ki?= , "patches@linaro.org" , Jan Kiszka , "qemu-devel@nongnu.org" , Paul Brook On 06/10/2011 09:59 AM, Markus Armbruster wrote: > Anthony Liguori writes: > >> 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] > > As Jan pointed out, ISA is a counter-example: your "very wrong" claim is > actually wrong there :) The wrongness comes from the fact that "irq=3" assumes that somehow the ISA device can get an IRQ from an index. If instead the example was: -device piix3,id=isa0 -device isa-serial,id=serial,irq=3,bus=isa0 With the implication isa-serial could use the "3" index to get an IRQ from it's bus at realize, like: void isa_serial_initfn() { ISAController *bus = qdev_get_isa_controller(dev, "bus"); connect_irq(dev->irq, bus->irq[qdev_get_int(dev, "irq")]); } That is at least conceptually okay but I don't think it's best. If you want to go this route, I'd actually model DIP switches or ISA plug and play. Usually devices would only allow you to choose between two of the 5 IRQs available. But personally, the modelling I mentioned in another part of the thread where you connect the IRQs directly to the device seems like a better compromise to me. > An ISA device is always connected to all the ISA bus's interrupt lines. > Device configuration determines how the device uses these lines. That's 100% correct. But the "ISA bus" is just a grouping of interfaces to another device. We shouldn't treat that as any more special than any other type of connection between devices. > The old (non-MSI) PCI interrupts are similar, I think. > > Of course, "ISA IRQ 4" can be anything, depending on how the device > providing the ISA bus is wired up. > >> 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. > > We already connect devices to other resources, such as block, char and > network host parts. The way we do it may not be "pure", but it works: > we define the plug as property, and connect it to its socket by saying > PROP-NAME=SOCK-NAME. Note that the connection is made by core qdev; > device model code is oblivious of it. It just uses it. Yes. The problem with this is namespaces. What you are referring to as "SOCK-NAME" is interpreted based on the property type. Ideally, we'd have a single namespace for everything. >> 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). > > Assumes that bus addresses are isomorphic to [0..N], doesn't it? > > Not really the case for USB: we use a string of the form %d(.%d)* there. Couple points there. 1) I didn't mean to suggest that the name "irq[3]" implies anything. I sort of thing it should be just treated as a string. It could as well be "irq[foo]". I'm not 100% here though. 2) USB addressing is expressing an implicit topology of HUBs. I think it's better to model those HUBs explicitly and leave convenience to syntactic sugar. For instance: -device usb-uhci,id=uhci0,ports=4,port0=hub0 -device usb-hub,id=hub0,ports=4,port1=tablet0 -device usb-tablet,id=tablet0 Which is the expansion of: -tablet address=0.1 > Not my idea. > > A bus is just a standardized container for slots. A single device can > provide multiple buses. Killing buses just unwraps the slots. You lose > the grouping. The grouping is still there by virtue of the fact that the slots are all part of the same device. > What exactly is so very wrong about buses that they need to die? They force a device tree. The device model shouldn't be a tree, but a directed graph. 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. Regards, Anthony Liguori > Honest, non-rhetorical question.