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]

Message-ID: <m1vdmvxe3u.fsf@fess.ebiederm.org>
Date:	Wed, 17 Jun 2009 05:02:29 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.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

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> I think we're getting off into the weeds a bit here.  I'm looking at other
> options of how to fit Xen interrupt handling into the kernel in a clean way; we
> may end up with a different model from the previous patch postings (not this
> particular one under discussion; the ones from last month).  We can reopen this
> discussion when I post those patches.
>
> However, the kernel will still need information about the I/O APICs from ACPI so
> that it can perform basic interrupt routing for PCI devices (ie, regardless of
> how the interrupt gets delivered, and who programs the APIC hardware, we still
> need the basic information of "what io apic+pin is this PCI device connected
> to?").  This particular patch is my attempt to achieve this.

Trying to understand what is going on I just read through Xen 3.4 and the
accompanying 2.6.18 kernel source.

Xen has a horrible api with respect to io_apics.  They aren't even real
io_apics when Xen is done ``abstracting'' them.

Xen gives us the vector to write.  But we get to assign that
vector arbitrarily to an ioapic and vector.

We are required to use a hypercall when performing the write.
Xen overrides the delivery_mode and destination, and occasionally
the mask bit.

We still have to handle polarity and the trigger mode.  Despite
the fact that Xen has acpi and mp tables parsers of it's own.

I expect it would have been easier and simpler all around if there
was just a map_gsi event channel hypercall.  But Xen has an abi
and an existing set of calls so could aren't worth worrying about
much.

Xen's ioapic affinity management logic looks like it only works
on sunny days if you don't stress it too hard.  Of course the hard
part Xen of driving the hardware Xen doesn't want to share.

It looks like the only thing Xen gains by pushing out the work of
setting the polarity and setting edge/level triggering is our database
of motherboards which get those things wrong.

So I expect the thing to do is factor out acpi_parse_ioapic,
mp_register_ioapic so we can share information on borked BIOS's
between the Xen dom0 port and otherwise push Xen pseudo apic handling
off into it's strange little corner.

Eric
--
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/