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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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