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: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Fri, 26 Feb 2010 16:17:29 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Zhang <xiantao.zhang@xxxxxxxxx>, Xiantao
Delivery-date: Fri, 26 Feb 2010 08:17:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1267185902.11737.12315.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <1267184533.11737.12277.camel@xxxxxxxxxxxxxxxxxxxxxx> <1267185902.11737.12315.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2010-02-26 at 12:05 +0000, Ian Campbell wrote:
> 
> Which looks might suspicious to me... However simply removing that
> causes acpi_probe_gsi to return 16 (instead of 24) and I run out of
> interrupts for use by real hardware (specifically my disk controller).
> If I hack acpi_probe_gsi to return at least 24 everything works OK so
> it seems the error is only at the detection stage. 

So this seems to all relate to the removal of the xen_io_apic_(read|
write) stuff.

I can see that the GSI routing stuff is effective replaced by
PHYSDEVOP_setup_gsi but I don't see what replaces the IO APIC
enumeration. We still map a dummy page for FIX_IO_ACPI_* and
io_apic_(read|write) now go at that direct (and therefore get 0s back).
If the intention is not to enumerate the IO APICs in this way then what
seems to be missing is the part which discovers the number of GSIs in
the system and I'm not sure what is supposed to replace that.

Perhaps the "max_gsi += 256" thing is simply supposed to cover the
largest possible use but in that case I think we also need to bump
nr_irqs to leave some space for dynamically created IRQ sources.

I guess I'm not sure what the intended approach here is, let along what
the right answer is.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel