Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-06-10 16:12, Anthony Liguori wrote:
> 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<aliguori@us.ibm.com>  wrote:
>>>> On 06/10/2011 03:13 AM, Markus Armbruster wrote:
>>>>>
>>>>> Jan Kiszka<jan.kiszka@siemens.com>   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.

I don't see the point of 'piix3.' in your IRQ assignment, though. It is
redundant to the bus assignment - as the ISA bus also routes interrupts.
There are surely also buses that don't. Still, interrupt routing via the
bus should be possible (as it avoids boilerplate code or configuration
redundancy).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux