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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/04/2011 10:03 AM, Avi Kivity wrote:
> On 09/04/2011 05:43 PM, Anthony Liguori wrote:
>>> 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).
>
> (we should have spent a few hours at kf2011 to convince you that this is
> impossible)

I don't mean for RAM, but for device I/O.

Instead of implementing it_shift in the core API, you could implement 
it_shift by having a device that takes an input MemoryRegion and an 
output MemoryRegion and implements the it_shift logic.

I think endianness could also be handled this way too.

For stuff like coalesced I/O and eventfds, I understand the difficulties.

>
>>
>> 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.
>
> Depends on the API. If Pin has a method pin_add_tristate_input(), then
> it becomes trivial.

See my self-reply to Jan.  I think there's a reasonable middle ground 
using an IrqRouter interface.

Regards,

Anthony Liguori