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

[Avi Kivity <avi@redhat.com>]

On 08/31/2011 01:53 PM, Jan Kiszka wrote:
> On 2011-08-31 10:25, Peter Maydell wrote:
> >  On 30 August 2011 20:28, Jan Kiszka<jan.kiszka@web.de>  wrote:
> >>  Yes, that's the current state. Once we have bidirectional IRQ links in
> >>  place (pushing downward, querying upward - required to skip IRQ routers
> >>  for fast, lockless deliveries), that should change again.
> >
> >  Can you elaborate a bit more on this? I don't think anybody has
> >  proposed links with their own internal state before in the qdev/qom
> >  discussions...
>
> That basic idea is to allow
>
> a) a discovery of the currently active IRQ path from source to sink
>     (that would be possible via QOM just using forward links)
>
> b) skip updating the states of IRQ routers in the common case, just
>     signaling directly the sink from the source (to allow in-kernel IRQ
>     delivery or to skip taking some device locks). Whenever some router
>     is queried for its current IRQ line state, it would have to ask the
>     preceding IRQ source for its state. So we need a backward link.
>
> We haven't thought about how this could be implemented in details yet
> though. Among other things, it heavily depends on the final QOM design.
>

Looks like a similar path to the memory API.  A declarative description 
of the interrupt hierarchy allows routes to be precalculated and flattened.

(here it's strictly an optimization; with the memory API it's a 
requirement since kvm requires a flattened representation, and tcg is 
greatly simplified by it).

-- 
error compiling committee.c: too many arguments to function