Re: kernel BUG at arch/x86/kernel/io_apic_64.c:357!

[Jeremy Fitzhardinge]

Eric W. Biederman wrote:
> > I'm still interested in making Xen's event channel-based interrupts fit better
> > into the rest of the interrupt handling scheme.  In particular, event channels
> > map very closely to the x86-64 notion of a vector.  There's 1024 of them per
> > domain, and each is bound to a cpu.  At the moment, I map them to irqs, which
> > means that I need to allocate around 5-6 irqs per cpu, which makes everything
> > very cluttered.  I'd like to map event channels to vectors, and then map vectors
> > to (irq,cpu) tuples.
> >     
>
> Uh....  I'm not certain this applies.
>   

No, but, hey, it's a hook.

> > From what I've seen this is exactly how x86-64 currently has things set up, and
> > I'm interested in making sure that 32-bit does the same thing.
> >     
>
> Yes. x86_32 needs work to get cleaned up.
>
> The architecture on x86_64 is as follows.
>
> We have interrupt sources:  GSIs in the case of acpi.
> We have linux interupts:  something with an irq number.
>
> Vectors are an internal implementation detail.
>
> I don't know if your event channels more closely resemble interrupt sources or internal
> implementation details.  If they are an implementation detail that interrupt sources
> just flow through we should hide them like we do vectors.  If event channels actually are
> the sources of interrupts we should do something different.
>   

They're an interrupt source, I guess.  They need to be behind some layer 
of indirection because they can be reassigned at arbitrary times (like 
suspend/resume, or if the backend driver just decided to disconnect 
itself), and so they need to get rebound to at least the same irq.

> > I'm also interested in having vectors being sourced from multiple interrupt
> > controllers.  So, some vectors would be sourced from APICs, and other are
> > sourced from event channels.  This would be useful for Xen domains which have
> > direct access to hardware (ie, the dom0 control domain in the short term, and
> > disaggregated driver domains later on), and fully emulated domains which have
> > paravirtual drivers.
> >     
>
> Generally easy except for the disparate methods of catching interrupts.
>   

Catching in what sense?  I assume the interrupt gets raised in some 
source-specific way, and then passed into a generic layer where it 
eventually gets matched with an appropriate handler.  I'm sure there's 
some subtlety I'm missing.

> > I haven't studied the current code to see if this notion already exists or not.
> >
> > While the APIC interrupt model is the most architecturally important for the x86
> > platform, I'd like to make sure we don't build in the assumption that it's the
> > *only* interrupt model.
> >     
>
> Well with iommus starting to show up in our irq paths it looks we are going to get
> a lot of diversity.
>
> Eric
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>   

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/