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/
Home Products Support Community News


[Xen-devel] [PATCH v2 2/2] x86: don't unmask disabled irqs when migratin

To: "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 6 May 2011 14:43:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "JBeulich@xxxxxxxxxx" <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 05 May 2011 23:47:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwLuH5jTtgKfhrsS1eB8mp4E9uMGg==
Thread-topic: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them
x86: don't unmask disabled irqs when migrating them

it doesn't make sense to mask/unmask a disabled irq when migrating it
from offlined cpu to another, because it's not expected to handle
any instance of it. Current mask/set_affinity/unmask steps may trigger
unexpected instance on disabled irq which then simply bug on when there
is no handler for it. One failing example is observed in Xen. Xen pvops 
guest marks a special type of irqs as disabled, which are simply used 
as a notification mechanism to wake up blocked guest in event polling
state. Absolutely unmask them may cause the notification instance 
instead injected into the guest and then cause trouble.

Signed-off-by: Fengzhe Zhang <fengzhe.zhang@xxxxxxxxx>
Signed-off-by: Kevin Tian <kevin.tian@xxxxxxxxx>
CC: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
CC: Ingo Molnar <mingo@xxxxxxxxxx>
CC: H. Peter Anvin <hpa@xxxxxxxxx>
CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
CC: Jan Beulich <JBeulich@xxxxxxxxxx>

--- linux-2.6.39-rc6.orig/arch/x86/kernel/irq.c 2011-05-04 10:59:13.000000000 
+++ linux-2.6.39-rc6/arch/x86/kernel/irq.c      2011-05-06 09:20:25.563963000 
@@ -237,6 +237,7 @@ void fixup_irqs(void)
        for_each_irq_desc(irq, desc) {
                int break_affinity = 0;
                int set_affinity = 1;
+               int do_mask;
                const struct cpumask *affinity;
                if (!desc)
@@ -268,7 +269,9 @@ void fixup_irqs(void)
                chip = irq_data_get_irq_chip(data);
-               if (!irqd_can_move_in_process_context(data) && chip->irq_mask)
+               do_mask = !irqd_irq_disabled(data) &&
+                       !irqd_can_move_in_process_context(data) && 
+               if (do_mask)
                if (chip->irq_set_affinity)
@@ -276,7 +279,7 @@ void fixup_irqs(void)
                else if (!(warned++))
                        set_affinity = 0;
-               if (!irqd_can_move_in_process_context(data) && chip->irq_unmask)
+               if (do_mask)

Xen-devel mailing list