linux-kernel - Re: [PATCH 30 of 38] xen: implement io_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: <m1prkpj3nl.fsf@frodo.ebiederm.org>
Date:	Thu, 20 Nov 2008 16:58:38 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
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

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

> 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.

It is hideous.  Been there and ripped out hundreds of lines of useless and problem
causing code to get here.  It is especially bad when you do not identity map the first
16 gsi to linux irqs (the legacy isa irqs).

It is very useful to keep the linux irq number and the gsi irq number the same.
It facilitates debugging and keeps the code simple.

> 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.

What I care about is important is that the GSI number == the linux irq number.

> 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.

Yep.  And but the numbers we you should be beyond the range of the gsi's so there
is no conflict.  Think of it an extension of how we identitly make the low 16 linux
irqs.

>  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).

MSI isn't sourced from an IOAPIC either.

The difference is that the xen sources are not delivered using vectors.  The cpu
vector numbers we do hide and treat as an implementation detail.  And I am totally
happy not going through the vector allocation path.

My gut feel says that you just want to use a different set of irq operations when
doing Xen native and working with hardware interrupts.    I haven't seen the code so
I don't know how you interact there.  Except in dom0 this is not a consideration so
I don't how it is handled.

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/