Re: CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xen/master and xen/next

[Jeremy Fitzhardinge <jeremy@goop.org>]

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