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

[Edgar E. Iglesias]

On Sun, Sep 04, 2011 at 08:57:31AM -0500, Anthony Liguori wrote:
> On 09/04/2011 08:49 AM, Jan Kiszka wrote:
> > On 2011-09-04 15:41, Anthony Liguori wrote:
> >> On 09/04/2011 08:36 AM, Jan Kiszka wrote:
> >>> On 2011-09-04 15:32, Anthony Liguori wrote:
> >>>> I prefer to not think of IRQs as special things.  They're just single
> >>>> bits of information that flow through the device model.  Having a higher
> >>>> level representation that understands something like paths seems wrong
> >>>> to me.
> >>>>
> >>>> I'd prefer to treat things like device assignment as a hack.  You just
> >>>> need code that can walk the device tree to figure out the path (which is
> >>>> not generic code, it's very machine specific).  Then you tell the kernel
> >>>> the resolution of the path and are otherwise completely oblivious in
> >>>> userspace.
> >>>
> >>> 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.
> >>
> >> Having some sort of global interrupt routing table is just going to add
> >> a layer of complexity for very little obvious gain.
> >
> > It's not yet decided how the problem is solved. A global interrupt
> > matrix is just one proposal, another option is to extend the pin model
> > in a way that supports routing change notifiers and backward polling.
> 
> If that's all you need, then you really just want notification on socket 
> changes.  Backwards polling can be achieved by just adding state to the 
> Pin (which I full heartedly support).

I'm not a fan of this backwards thing, but seeing the options available,
it might be the simplest way forward.

I agree that the global interrupt manager sounds like overkill...

Cheers