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
| ||
|
Date: Thu, 20 Nov 2008 13:32:18 -0800 From: Jeremy Fitzhardinge <jeremy@...p.org> To: "Eric W. Biederman" <ebiederm@...ssion.com> CC: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org, Xen-devel <xen-devel@...ts.xensource.com>, the arch/x86 maintainers <x86@...nel.org>, Ian Campbell <ian.campbell@...rix.com>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, Yinghai Lu <yinghai@...nel.org> Subject: Re: [PATCH 30 of 38] xen: implement io_apic_ops Eric W. Biederman wrote: > Jeremy Fitzhardinge <jeremy@...p.org> writes: > > >> Ingo Molnar wrote: >> >>> * Jeremy Fitzhardinge <jeremy@...p.org> wrote: >>> >>> >>> >>>> Writes to the IO APIC are paravirtualized via hypercalls, so implement >>>> the appropriate operations. >>>> >>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com> >>>> --- >>>> arch/x86/xen/Makefile | 3 +- >>>> arch/x86/xen/apic.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++ >>>> arch/x86/xen/enlighten.c | 2 + >>>> arch/x86/xen/xen-ops.h | 2 + >>>> 4 files changed, 72 insertions(+), 1 deletion(-) >>>> >>>> >>> hm, why is the ioapic used as the API here, and not an irqchip? >>> >>> >> In essence, the purpose of the series is to break the 1:1 relationship between >> Linux irqs and hardware GSIs. >> > > Bad idea (I think). We have a 1:1 relationship between the linux irq number and > the GSI because it makes the code dramatically simpler, and it took significant > work to get there. The concept of an intermediate mapping layer sounds nasty. > But I haven't yet read the patch. > The changes are spread over a number of patches, but the meat of it is in "xen: route hardware irqs via Xen". It turns out fairly simply, but perhaps its because I've made a number of simplifying assumptions: interrupts are always IOAPIC based, only using ACPI for routing, no MSI support yet. But it seems to me that the only time you really care that the irq isn't a gsi is when programming a vector into the ioapics - you need to do a irq -> ioapic/pin mapping anyway, so adding a irq -> gsi -> ioapic/pin map isn't all that complex. And conversely, when probing devices you need to map gsi->irq to see whether the interrupt is shared, though you could do that on a pure gsi level anyway. And of course the current code isn't purely irq == gsi anyway, since msis are allocated irqs as well, and there's no underlying gsi. In a sense you can think of the other Xen interrupt sources as being a bit like MSI, at least in as much as they're not sourced from a GSI (but they go further and are not sourced from an IOAPIC at all). J -- 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/
Powered by blists - more mailing lists