From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV2SD-0004UA-Se for qemu-devel@nongnu.org; Fri, 10 Jun 2011 10:12:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QV2SB-0007SD-4j for qemu-devel@nongnu.org; Fri, 10 Jun 2011 10:12:53 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:33774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV2SA-0007Rr-KP for qemu-devel@nongnu.org; Fri, 10 Jun 2011 10:12:50 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5ADpPGI021741 for ; Fri, 10 Jun 2011 09:51:25 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5AECnig104412 for ; Fri, 10 Jun 2011 10:12:49 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5A8CUlu026856 for ; Fri, 10 Jun 2011 02:12:34 -0600 Message-ID: <4DF2264C.6080609@us.ibm.com> Date: Fri, 10 Jun 2011 09:12:28 -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> <4DF21F97.4070709@siemens.com> In-Reply-To: <4DF21F97.4070709@siemens.com> Content-Type: text/plain; charset=UTF-8; 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: Jan Kiszka Cc: Peter Maydell , =?UTF-8?B?SnVoYSBSaWloaW3DpGtp?= , "patches@linaro.org" , "qemu-devel@nongnu.org" , Markus Armbruster , Paul Brook On 06/10/2011 08:43 AM, Jan Kiszka wrote: > On 2011-06-10 15:10, Peter Maydell wrote: >> On 10 June 2011 13:51, Anthony Liguori wrote: >>> 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. > > Generally true. Two exceptions still require to make the path explorable > / transfer information in the reverse direction: IRQ de-coalescing and > physical device assignment. That's something a new generic API should > encapsulate so that we can stop peaking into the machine details. > >>> >>> 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. >> >> Actually, devices have input and output I/O signals (GPIOs, if you like). >> A subset of these are IRQs. We already have some APIs in QEMU which >> claim to be dealing with 'irq's but actually are just for wiring >> up generic signals; I'd rather we didn't proliferate that terminology >> confusion if possible. (And a single GPIO wire is just one kind of >> thing you might want to link between two devices, obviously. MMIO is >> another.) >> >>> 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] >> >> This makes the wiring of this signal look like a property of the >> isa-serial device, which is a bit odd, since it's just as much >> a property of the piix3. Actually it's neither, it's a property >> of the machine model, and you might actually want a syntax a bit >> more like: >> >> piix3 = piix3(property=value, property=value...); >> serial = isa-serial(property=value...); >> connect(serial.irq, piix3.irq[3]); > > In fact, in the ISA case, it is a device property: The device, and only > the device decides which IRQ to use - from the bus it is attached to. So > attaching an ISA device to the bus of an ISA bridge like the PIIX3 and > selecting local IRQ 3 are the steps we can already express today. If you really want to be pedantic, each ISA device has 5 input Pins that are supposed to correspond to IRQ 3, IRQ 4, IRQ 5, IRQ 6, and IRQ 7. This could easily be modelled by doing the following: -device piix3,id=piix3 -device isa-serial,id=serial,irq[3]=piix3.irq[3],irq[4]=piix3.irq[4],... But I don't think we benefit from modelling it this correctly. The point is that the infrastructure could handle it though. Regards, Anthony Liguori > > Jan >