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] [PATCH] xen: do not unmask disabled IRQ on eoi.

To: jeremy@xxxxxxxx
Subject: [Xen-devel] [PATCH] xen: do not unmask disabled IRQ on eoi.
From: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date: Fri, 15 Oct 2010 11:52:45 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Campbell <ian.campbell@xxxxxxxxxx>
Delivery-date: Fri, 15 Oct 2010 03:54:26 -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
This prevents a guest from being able to trigger an interrupt storm in
dom0 rendering it inoperable. In particular this effects event
channels delivered to userspace by the /dev/xen/evtchn driver which
uses disable_irq in its interupt handler to prevent further interrupts
firing until the interrupt has been handled by the userspace
application and it has requested an unmask. Without this patch the
event channel is re-enabled immediately after the interrupt handler
completes.

The issue was introduced by 0672fb44a111 "xen/events: change to using
fasteoi".

In the specific instance I saw a domU would spin sending console event
channel notifications to dom0 because its console ring was full (this
behaviour has since been tempered by f3483182666a "xen/hvc: only
notify if we actually sent something") but xenconsoled would be unable
to run due to the storm and hence the ring would never be drained.

I'm not convinced this is the right way to go about this -- there does
not seem to be much precedent and I would have expected some sort of
generic handling but I cannot see any.

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
---
 drivers/xen/events.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 1496ba5..a9b0637 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1215,6 +1215,17 @@ int resend_irq_on_evtchn(unsigned int irq)
        return 1;
 }
 
+static void eoi_dynirq(unsigned int irq)
+{
+       struct irq_desc *desc = irq_to_desc(irq);
+       int evtchn = evtchn_from_irq(irq);
+
+       move_masked_irq(irq);
+
+       if (VALID_EVTCHN(evtchn) & !(desc->status & IRQ_DISABLED))
+               unmask_evtchn(evtchn);
+}
+
 static void ack_dynirq(unsigned int irq)
 {
        int evtchn = evtchn_from_irq(irq);
@@ -1408,7 +1419,7 @@ static struct irq_chip xen_dynamic_chip __read_mostly = {
        .mask           = mask_irq,
        .unmask         = unmask_irq,
 
-       .eoi            = ack_dynirq,
+       .eoi            = eoi_dynirq,
        .set_affinity   = set_affinity_irq,
        .retrigger      = retrigger_irq,
 };
-- 
1.5.6.5


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