Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Thu, 18 Jun 2009, Jeremy Fitzhardinge wrote:

> Perhaps I should have expressed that a bit more clearly:  you could, if
> mad, build a machine with I/O APICs and some other mechanism for
> delivering the interrupts to CPUs.  In practice, I doubt anyone ever
> has, or ever would.

 And people have done that (not for the x86 though) -- any machine with an 
HT bus will have I/O APIC interrupts as this is how the interconnect 
carries over interrupt messages from devices.  The root HT bridge forwards 
these messages to the local APIC -- this is similar to how MSI messages 
work; in fact if the upstream HT bridge was not a root bridge, but a 
PCI-HT bridge instead, then this is how these interrupt messages would 
have to be forwarded to the root PCI bridge.

 Now with a non-x86 machine there is not necessarily a real local APIC 
component -- this is the case for example with the Broadcom BCM1250A SOC 
based around a pair of MIPS64 processor cores.  Still this chip has to 
provide some logic to map HT interrupt messages to native interrupts and 
it is there, providing means for routing messages to the correct CPUs 
based on the destination and the destination mode and for the delivery 
mode and the vector (if applicable) to select the correct native interrupt 
source.  ExtINTA and EOI cycles have to be performed by software 
explicitly though, by poking at the right MMIO addresses which are not 
associated with the HT interrupt reception logic.  Not exactly an 
x86-style local APIC, but still an analogue.

 Just for the record.  I wholeheartedly agree with Eric pretending there 
is no local APIC and fiddling with our fragile code which assumes 
otherwise is not the best thing to do.  The Broadcom platform mentioned 
does not reuse any piece of our x86 APIC code.

  Maciej