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: <m1hbydohhz.fsf@fess.ebiederm.org>
Date:	Thu, 18 Jun 2009 05:26:16 -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>,
	Keir Fraser <keir.fraser@...citrix.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:

> Actually I was discussing this with Keir yesterday.  We're definitely open to
> changing the dom0 API to make things simpler on the Linux side.  (The dom0 ABI
> is more fluid than the domU one, and these changes would be backwards-compatible
> anyway.)
>
> One of the options we discussed was changing the API to get rid of the exposed
> vector, and just replace it with an operation to directly bind a gsi to a pirq
> (internal Xen physical interrupt handle, if you will), so that Xen ends up doing
> all the I/O APIC programming internally, as well as the local APIC.
>
> On the Linux side, I think it means we can just point pcibios_enable/disable_irq
> to our own xen_pci_irq_enable/disable functions to create the binding between a
> PCI device and an irq.

Then let's make this the plan.  Design a supportable dom0 <-> kernel
irq abi.  Essentially binding a gsi to an event channel mapping
function.  Get that into Xen.  Then get that into the mainstream linux
kernel.

Regardless of the upstream linux kernel merge status cleaning up the
irq handling is going to have to happen to move past 2.6.18.  I cleaned the
irq code up and changed it to work in incompatible ways starting in 2.6.19.

I really REALLY don't want to see support for Xen 3.4 domU irq
handling in the mainline linux kernel.  It is an evolutionary dead
end, and I have already ripped that code out of linux once.  Vectors
should be an implementation detail not an exposed part of the ABI.

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/