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 17:16:23 -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 17:17:11 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<m1prkpj3nl.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> <4925D762.6040406@xxxxxxxx> <m1prkpj3nl.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:
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).
Yes. I made that concession too, and just reserved them as identity
mapped legacy irqs.
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.
Yes, I suppose we can statically partition the irq space. In fact the
original 2.6.18-xen dom0 kernel does precisely that, but runs into
limitations because of the compile-time limit on NR_IRQS in that
kernel. If we move to a purely dynamically allocated irq space, then
having a sparse allocation if irqs becomes reasonable again, for msis
and vectorless Xen interrupts.
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.
Right.
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.
Right. And in the physical irq event channel case, the vector space is
managed by Xen, so we need to use Xen to allocate the vector, then
program that into the appropriate place in the ioapic.
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.
Yeah. In the domU case, where there's no physical interrupts, the Xen
code completely avoids the ioapic/vector stuff, and directly converts an
event channel into an irq. Indeed, physical irq delivery is handled the
same way; its just that the setup requires touching the ioapics to
program the appropriate vector and bind it to an event channel.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] [PATCH 32 of 38] xen: use our own eventchannel->irq path, (continued)
- [Xen-devel] [PATCH 32 of 38] xen: use our own eventchannel->irq path, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 31 of 38] xen: set irq_chip disable, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 37 of 38] xen: bind pirq to vector and event channel, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 30 of 38] xen: implement io_apic_ops, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 34 of 38] xen: remove irq bindcount, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 38 of 38] xen: make sure that softirqs get handled at the end of event processing, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 29 of 38] xen: create dummy ioapic mapping, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 28 of 38] paravirt/xen: add pvop for page_is_ram, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 35 of 38] xen: implement pirq type event channels, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 33 of 38] xen: pack all irq-related info together, Jeremy Fitzhardinge
- [Xen-devel] [PATCH 36 of 38] xen: route hardware irqs via Xen, Jeremy Fitzhardinge
|
|
|