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

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

Jeremy Fitzhardinge wrote:
> 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()?

Okay, add_nr_irqs_gsi maybe a better option, and it can avoid 
{get,set}_nr_irqs_gsi as well.  
I will cook a patch for that. 
Xiantao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel