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
|
Home