Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/04/2011 09:12 AM, Avi Kivity wrote:
> On 09/04/2011 04:41 PM, Anthony Liguori wrote:
>>> See it as you like, but we need the support, not only for device
>>> assigment. And I do not see any gain it hacking this instead of
>>> designing it.
>>
>>
>> You can design a hack but it's still a hack.
>>
>> Device state belongs in devices. Trying to extract device state
>> (interrupt routing paths) and externalizing it is by definition a hack.
>
> Pet peeve - saying something is "by definition" a hack is just rhetoric
> unless the definition of device state is "something that cannot be
> extracted and externalized". Let's avoid this.

Likewise, I would prefer to avoid stating that something is a hard 
requirement in the absence of concrete use-cases.

I do think the definition of device state is more or less something that 
is opaque and owned by the device.  The more we externalize the device 
state, the more we have to deal with compatibility (even if it's just 
internal compatibility).  This makes modularity hard because there's too 
many things with complex dependencies.

> In fact it's exactly what we do with the memory API. Memory routing is
> part of device state, yet we expose it to the memory API and let it do
> its thing instead of going through the hierarchy on every single memory
> access.

Yes, and the memory API is complicated and invasive :-)  But it's worth 
it at the end of the day (although I think it could be simplified at the 
expensive of not allowing as much flattening).

> Whether it's worthwhile to do this for interrupts as well depends on how
> common the situation is and what we gain from it. We can only do this if
> the routing is semi-static (depends only on other state but not the
> actual interrupt) - probably the only exception to this is the "least
> priority" mode which means the last leg cannot be computed statically.
>
> I agree the gain is low if we limit ourselves to 440fx, but if we add
> interrupt remapping it becomes considerably more complicated to do this
> backward path computation.

If we start with a simple interface that works for the i440fx and then 
expand it as we support more layers, I think we'll be okay.

What I'm concerned about is an attempt to globally track IRQ routing.  I 
can imagine constructing a board where you have two simple devices that 
have level triggered interrupts and wanting to tie them to a single 
input pin.  A simple OR gate would be sufficient to do this.  Having to 
make an OR gate an IRQ router seems like far too much complexity to me.

I think we need to strive to keep simple things simple.

Regards,

Anthony Liguori