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

[Xen-devel] Re: [PATCH] Fix when booting Xen+Linux under QEMU.

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Fix when booting Xen+Linux under QEMU.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 10 Dec 2010 13:02:52 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Stefano, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Rzeszutek Wilk <konrad@xxxxxxxxxx>, Konrad
Delivery-date: Fri, 10 Dec 2010 05:03:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D01462A.4010808@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: <1291928497-5599-1-git-send-email-konrad.wilk@xxxxxxxxxx> <4D01462A.4010808@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 9 Dec 2010, Jeremy Fitzhardinge wrote:
>    2. kill the ioapic dummy page hack (I'm assuming that would be
>       trivial - at least to make it all zero - because the kernel won't
>       care about the number of GSIs at that point)
 
That wouldn't work: mp_register_ioapic reads the number of entries for
each ioapic and it cannot be zero, because later on mp_find_ioapic is
going to find the ioapic a particular gsi belongs to based on the
previous results.
Mp_register_ioapic also increases gsi_top that ends up influencing the
value of nr_irqs_gsi.


Considering that nr_irqs is not a real upper limit on Xen because you
usually have at least 1024 evtchns anyway, I think we should reimplement
arch_probe_nr_irqs on Xen to set nr_irqs appropriately.
Something like this:

#define NR_EVTCHNS (sizeof(unsigned long) * 8 * sizeof(unsigned long))
int __init arch_probe_nr_irqs(void)
{
        if (xen_domain())
                nr_irqs = NR_EVTCHNS;
    
    return NR_IRQS_LEGACY;
}

The problem is that #ifdef CONFIG_SPARSE_IRQ io_apic.c reimplements
arch_probe_nr_irqs too but only if CONFIG_PCI_MSI is also defined
nr_irqs is set high enough by that function.
So to work around this problem we might have to redefine
arch_probe_nr_irqs only #if !defined(CONFIG_SPARSE_IRQ) and we might also
have to automatically enable CONFIG_PCI_MSI if the user selects
CONFIG_SPARSE_IRQ on XEN somehow.

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

<Prev in Thread] Current Thread [Next in Thread>