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

[Anthony Liguori]

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