xen-devel
[Xen-devel] Re: [PATCH 30 of 38] xen: implement io_apic_ops
To: |
"Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH 30 of 38] xen: implement io_apic_ops |
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Date: |
Thu, 20 Nov 2008 13:32:18 -0800 |
Cc: |
Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Yinghai Lu <yinghai@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx> |
Delivery-date: |
Thu, 20 Nov 2008 13:33:02 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<m1y6ze87w6.fsf@xxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<patchbomb.1226603398@xxxxxxxxxxxxxxxxx> <d103c0da2fa147ac31af.1226603428@xxxxxxxxxxxxxxxxx> <20081120093506.GB6885@xxxxxxx> <492597B9.8070506@xxxxxxxx> <m1y6ze87w6.fsf@xxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Thunderbird 2.0.0.17 (X11/20081009) |
Eric W. Biederman wrote:
Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:
Ingo Molnar wrote:
* Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
Writes to the IO APIC are paravirtualized via hypercalls, so implement
the appropriate operations.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
---
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|