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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xen/master and xen/next
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Fri, 5 Mar 2010 10:41:23 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Thu, 04 Mar 2010 18:42:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B8EE42D.2090702@xxxxxxxx>
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> <4B8EE42D.2090702@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acq7IdbvHKyyJeL9SymGqESf9TXECQA6rhAQ
Thread-topic: [Xen-devel] CONFIG_SPARSE_IRQ breaks single VCPU domain 0 between xen/master and xen/next
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