|
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: |
Mon, 24 Nov 2008 11:18:20 -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: |
Mon, 24 Nov 2008 11:18:43 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<m1tza1hffa.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> <49260BE7.1080909@xxxxxxxx> <m1tza1hffa.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:
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.
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.
We should be able to share code with iommu for irqs handling, at first glance
you
are describing a pretty similar problem. Now I don't know think the interrupt
remapping code is any kind of beauty but that seems to be roughly what you
are doing with Xen domU. I certainly think with some careful factoring
we can share the ioapic munging code. And the code to pick how we program
the ioapics.
Notwithstanding the possibility that there'll be general changes to x86
interrupt handing in the future, do you have any objection to my patches
as they stand? Ingo would like to see your and/or hpa's ack before
accepting them.
Should I repost them?
Thanks,
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home