WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xe

To: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Subject: Re: [Xen-devel] CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xen/master and xen/next
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 03 Mar 2010 14:35:25 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Wed, 03 Mar 2010 14:40:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <EB8593BCECAB3D40A8248BE0B6400A3846255829@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1267184533.11737.12277.camel@xxxxxxxxxxxxxxxxxxxxxx> <1267185902.11737.12315.camel@xxxxxxxxxxxxxxxxxxxxxx> <1267201049.11737.12593.camel@xxxxxxxxxxxxxxxxxxxxxx> <4B8804D1.70408@xxxxxxxx> <EB8593BCECAB3D40A8248BE0B6400A3846255829@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100225 Fedora/3.0.2-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.2
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