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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Jun 2009 23:51:19 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Len Brown <lenb@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>
Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's
 no local APIC

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