| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xe
On 03/01/2010 04:34 AM, Zhang, Xiantao wrote:
Currenlty, ioapic access only exists at kernel's boot time to probe some info
related to ioapic(e.g. ioapic version, ioapic's rte number), and no any access
to ioapic at runtime, and this is why we still need the dump page there.
To remove the hack, we can use your third method with existing interface
PHYSDEVOP_apic_read to read the redirect entry number of ioapic. Attached the
patch. What's your opinion ? :)
From e5a75b3f2f40e56de714818b51932e6f36491f56 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang<xiantao.zhang@xxxxxxxxx>
Date: Mon, 1 Mar 2010 19:06:43 -0500
Subject: [PATCH] x86: ioapic: Remove the hack for calculating nr_irq_gsi for
Xen.
Read the entry number through the hypercall PHYSDEVOP_apic_read, but
the default vaule is also set to 255 if PHYSDEVOP_apic_read doesn't
exist.
This doesn't look too bad, but I wonder if there's a cleaner way of
integrating it into the ioapic code path. Hm, nothing obvious. I'd
almost be tempted to just add something like:
nr_irqs_gsi = xen_probe_gsi(nr_irqs_gsi);
to the end of probe_nr_irqs_gsi(). It does have the downside of adding
Xen-specific code here, but it has the upside of being fairly clear and
to the point, and doesn't add a somewhat arbitrary interface like
set_nr_irqs_gsi().
At the very least, I think we can get rid of get_nr_irqs_gsi() as we add
set_nr_irqs_gsi()...
And should set_nr_irqs_gsi() refuse to decrease nr_irqs_gsi? Perhaps it
should be add_nr_irqs_gsi()?
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home