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] Modpost section mismatch fix

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Modpost section mismatch fix
From: Raghavendra D Prabhu <rprabhu@xxxxxxxxxxx>
Date: Thu, 7 Jul 2011 21:16:48 +0530
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, jeremy.fitzhardinge@xxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Ian Campbell <ijc@xxxxxxxxxxxxxx>
Delivery-date: Thu, 07 Jul 2011 08:47:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=wnohang.net; s=mail; t=1310053616; bh=VfTOuVWCZb2mSP1E2B40WvVqi9814XKfk818d24OapA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=OcQaWR78q0kknuKnW6hU3Xvjwg0qbC25GpD+DF4B8ZJ7nxgA7lM7j7Ovc3Rd/leDH IEb4lLwmucbjeNYdRFTdepWRVgXHRACw1C8YAFz91ONhoHLbskhr/YaAd/fEiPNiqy fgHH7QdqGCQO6W2efhafNk3BJESW+WwggsiAbJUE=
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=wnohang.net; s=mail; t=1310053614; bh=VfTOuVWCZb2mSP1E2B40WvVqi9814XKfk818d24OapA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=nAIxLlwVEv3I7PzyQqimXDX9+SwaUyO2pUsk9jT0D+kNnZB1WHOoWhGlw0jCXEa1F Nfo0+JTw5AIuA8OVZS4zZAfRZDJGZTBtwQCujdg5QYdVfkkz3xsDGBK+MB7kfdmPY2 akrXeeRE0aE27soiAs5JU0oing3di9hwranzZamU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110705213243.GA3647@xxxxxxxxxxxx>
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: <20110703232508.GB4440@Xye> <1309769388.634.51.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110704221646.GB4490@Xye> <20110705141323.GG2972@xxxxxxxxxxxx> <20110705142731.GA4463@Xye> <20110705144846.GA13548@xxxxxxxxxxxx> <20110705213243.GA3647@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-12-30)
* On Tue, Jul 05, 2011 at 05:32:43PM -0400, Konrad Rzeszutek Wilk 
<konrad.wilk@xxxxxxxxxx> wrote:
On Tue, Jul 05, 2011 at 10:48:46AM -0400, Konrad Rzeszutek Wilk wrote:
> >>xen_register_gsi and hence, xen_register_pirq are called from
> >>init (with xen_setup_acpi_sci) and non-init (with
> >>acpi_register_gsi_xen); since xen_set_acpi_sci calls it with gsi ==
> >>acpi_sci_override_gsi and is marked __init, the best way would be to
> >>call xen_register_gsi and xen_register_pirq with a boolean argument like
> >>sci_override to obviate the need to use acpi_sci_override_gsi in
> >>register_pirq. I will send the patch with this change if it looks good.

> >Hold on, let me rebase #stable/pci.cleanups and see if the issue
> >here disappears.
> Thanks, will wait until the rebase and test after that.

Hm, it actually looks like it wont do the trick. Why don't you send
a patch against 3.0-rc6 with the outlined mechanism mentioned above.

Or this patch (against 3.0-rc6) might do the trick:

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index fe00830..f567965 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -327,13 +327,12 @@ int __init pci_xen_hvm_init(void)
}

#ifdef CONFIG_XEN_DOM0
-static int xen_register_pirq(u32 gsi, int triggering)
+static int xen_register_pirq(u32 gsi, int gsi_override, int triggering)
{
        int rc, pirq, irq = -1;
        struct physdev_map_pirq map_irq;
        int shareable = 0;
        char *name;
-       bool gsi_override = false;

        if (!xen_pv_domain())
                return -1;
@@ -345,31 +344,12 @@ static int xen_register_pirq(u32 gsi, int triggering)
                shareable = 1;
                name = "ioapic-level";
        }
-
        pirq = xen_allocate_pirq_gsi(gsi);
        if (pirq < 0)
                goto out;

-       /* Before we bind the GSI to a Linux IRQ, check whether
-        * we need to override it with bus_irq (IRQ) value. Usually for
-        * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
-        *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
-        * but there are oddballs where the IRQ != GSI:
-        *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
-        * which ends up being: gsi_to_irq[9] == 20
-        * (which is what acpi_gsi_to_irq ends up calling when starting the
-        * the ACPI interpreter and keels over since IRQ 9 has not been
-        * setup as we had setup IRQ 20 for it).
-        */
-       if (gsi == acpi_sci_override_gsi) {
-               /* Check whether the GSI != IRQ */
-               acpi_gsi_to_irq(gsi, &irq);
-               if (irq != gsi)
-                       /* Bugger, we MUST have that IRQ. */
-                       gsi_override = true;
-       }
-       if (gsi_override)
-               irq = xen_bind_pirq_gsi_to_irq(irq, pirq, shareable, name);
+       if (gsi_override >= 0)
+               irq = xen_bind_pirq_gsi_to_irq(gsi_override, pirq, shareable, 
name);
        else
                irq = xen_bind_pirq_gsi_to_irq(gsi, pirq, shareable, name);
        if (irq < 0)
@@ -392,7 +372,7 @@ out:
        return irq;
}

-static int xen_register_gsi(u32 gsi, int triggering, int polarity)
+static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int 
polarity)
{
        int rc, irq;
        struct physdev_setup_gsi setup_gsi;
@@ -403,7 +383,7 @@ static int xen_register_gsi(u32 gsi, int triggering, int 
polarity)
        printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
                        gsi, triggering, polarity);

-       irq = xen_register_pirq(gsi, triggering);
+       irq = xen_register_pirq(gsi, gsi_override, triggering);

        setup_gsi.gsi = gsi;
        setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
@@ -425,6 +405,8 @@ static __init void xen_setup_acpi_sci(void)
        int rc;
        int trigger, polarity;
        int gsi = acpi_sci_override_gsi;
+       int irq = -1;
+       int gsi_override = -1;

        if (!gsi)
                return;
@@ -441,7 +423,25 @@ static __init void xen_setup_acpi_sci(void)
        printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
                        "polarity=%d\n", gsi, trigger, polarity);

-       gsi = xen_register_gsi(gsi, trigger, polarity);
+       /* Before we bind the GSI to a Linux IRQ, check whether
+        * we need to override it with bus_irq (IRQ) value. Usually for
+        * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
+        *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
+        * but there are oddballs where the IRQ != GSI:
+        *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
+        * which ends up being: gsi_to_irq[9] == 20
+        * (which is what acpi_gsi_to_irq ends up calling when starting the
+        * the ACPI interpreter and keels over since IRQ 9 has not been
+        * setup as we had setup IRQ 20 for it).
+        */
+       /* Check whether the GSI != IRQ */
+       if (acpi_gsi_to_irq(gsi, &irq) == 0) {
+               if (irq >= 0 && irq != gsi)
+                       /* Bugger, we MUST have that IRQ. */
+                       gsi_override = irq;
+       }
+
+       gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
        printk(KERN_INFO "xen: acpi sci %d\n", gsi);

        return;
@@ -450,7 +450,7 @@ static __init void xen_setup_acpi_sci(void)
static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
                                 int trigger, int polarity)
{
-       return xen_register_gsi(gsi, trigger, polarity);
+       return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, 
polarity);
}

static int __init pci_xen_initial_domain(void)
@@ -489,7 +489,7 @@ void __init xen_setup_pirqs(void)
                if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
                        continue;

-               xen_register_pirq(irq,
+               xen_register_pirq(irq, -1 /* no GSI override */,
                        trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE);
        }
}

Tested it. Works now.
Reviewed-by: Raghavendra Prabhu <rprabhu@xxxxxxxxxxx>

Also,
The condition for acpi_gsi_to_irq can be removed since it always returns zero.
============================================
 diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
 index f567965..3faa55b 100644
 --- a/arch/x86/pci/xen.c
 +++ b/arch/x86/pci/xen.c
 @@ -405,7 +405,7 @@ static __init void xen_setup_acpi_sci(void)
         int rc;
         int trigger, polarity;
         int gsi = acpi_sci_override_gsi;
 -       int irq = -1;
 +       unsigned int irq = 0u;
         int gsi_override = -1;

         if (!gsi)
 @@ -435,11 +435,10 @@ static __init void xen_setup_acpi_sci(void)
          * setup as we had setup IRQ 20 for it).
          */
         /* Check whether the GSI != IRQ */
 -       if (acpi_gsi_to_irq(gsi, &irq) == 0) {
 -               if (irq >= 0 && irq != gsi)
 -                       /* Bugger, we MUST have that IRQ. */
 -                       gsi_override = irq;
 -       }
 +       acpi_gsi_to_irq(gsi, &irq);
 +       if (irq != gsi)
 +               /* Bugger, we MUST have that IRQ. */
 +               gsi_override = irq;

         gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
         printk(KERN_INFO "xen: acpi sci %d\n", gsi);


--------------------------
Raghavendra Prabhu
GPG Id : 0xD72BE977
Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
www: wnohang.net

Attachment: pgplrcvW52cNB.pgp
Description: PGP signature

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