| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xe
On 02/26/2010 08:17 AM, Ian Campbell wrote:
On Fri, 2010-02-26 at 12:05 +0000, Ian Campbell wrote:
Which looks might suspicious to me... However simply removing that
causes acpi_probe_gsi to return 16 (instead of 24) and I run out of
interrupts for use by real hardware (specifically my disk controller).
If I hack acpi_probe_gsi to return at least 24 everything works OK so
it seems the error is only at the detection stage.
So this seems to all relate to the removal of the xen_io_apic_(read|
write) stuff.
Yep.
I can see that the GSI routing stuff is effective replaced by
PHYSDEVOP_setup_gsi but I don't see what replaces the IO APIC
enumeration. We still map a dummy page for FIX_IO_ACPI_* and
io_apic_(read|write) now go at that direct (and therefore get 0s back).
If the intention is not to enumerate the IO APICs in this way then what
seems to be missing is the part which discovers the number of GSIs in
the system and I'm not sure what is supposed to replace that.
Nothing, as yet. The "+= 256" is definitely a hack, and we need to come
up with a sound way to resolve it. There seem to be three possibilities:
* Let the kernel see the IO APICs for the purposes of enumeration,
but nothing else (which seems to defeat the point of the exercise)
* Make up a fake Xen IO APIC mapping which just contains static
state for the config registers. (I don't think this will work,
because the IO APIC registers aren't simply memory-mapped)
* Add an interface to Xen so it can return the results of its own IO
APIC enumeration, and use that in dom0. I think this is probably
most consistent with the idea that "Xen owns all the APICs", but
I'm not sure how to wire it into the Linux side.
Ideally we should also be able to get rid of the fake IO APIC mappings
because nothing in Linux will even attempt to access them, but I suspect
in practice it will be easier to let some probe code poke at them and
find they're not there rather than try and disable the probe.
I think Xiantao has some thoughts on this too.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home