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

[Jeremy Fitzhardinge <jeremy@goop.org>]

Eric W. Biederman wrote:
> Sorry.  Probably too much context in my head.
> The model I use is irq sources throw interrupts and then the cpus catch them.
> Sometimes those in flight irqs go through several transformations.
>   

OK, that's more or less my mental model too.

> Given that the event channels that logical irq are bound to change over time
> I would say they appear to be not irq sources.  Those are the physical
> lines coming out of hardware devices (if physical), and the equivalent
> parts of the hardware when the irqs are sent message based.
>
> So it does sound like the event channels function much like vectors.  Which
> are the token thrown from ioapics to cpus to tell them which irq has happened
> but have nothing to do with it.
>   

Yes and no.  The event channels are similar to the actual interrupt 
wires coming out of a PCI card, but they generally connect to virtual 
devices, and so are a lot more dynamic than physical devices.  The event 
channel remapping scenario I described is pretty much exactly analogous 
to having a hotplug PCI device being pulled and then replugged into a 
different slot with a different interrupt line.

> The sources and the linux irq numbers should be stable if you don't unplug
> anything.  The rest are implementation details the architecture should hide.
>   

Yeah, plugging can happen as a quite regular thing.

> In that case I don't see any reason we could not be receiving irqs with the
> cpus catching vectors and with events showing up in event channels.  Having
> both running at the same time is a little odd but doable.
>   

Yes, it's a bit odd, but there are two distinct configurations where 
it's a useful thing to have, where the system is running in a hybrid 
Xen/native environment.

    J