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

[Jeremy Fitzhardinge <jeremy@goop.org>]

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@intel.com>
> 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