From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xen/master and xen/next Date: Wed, 03 Mar 2010 14:35:25 -0800 Message-ID: <4B8EE42D.2090702@goop.org> References: <1267184533.11737.12277.camel@zakaz.uk.xensource.com> <1267185902.11737.12315.camel@zakaz.uk.xensource.com> <1267201049.11737.12593.camel@zakaz.uk.xensource.com> <4B8804D1.70408@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Zhang, Xiantao" Cc: "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.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 > 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