Re: [Xen-devel] CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xen/master and xen/next

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

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.

Perhaps the "max_gsi += 256" thing is simply supposed to cover the
largest possible use but in that case I think we also need to bump
nr_irqs to leave some space for dynamically created IRQ sources.

I guess I'm not sure what the intended approach here is, let along what
the right answer is.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel