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-changelog] [xen-unstable] [PV-ON-HVM] Don't generate lots of spurio

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] [PV-ON-HVM] Don't generate lots of spurious interrupts when using event
From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 31 Oct 2006 17:40:15 +0000
Delivery-date: Thu, 02 Nov 2006 13:45:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User Steven Smith <ssmith@xxxxxxxxxxxxx>
# Node ID 79a40acadb41fbe5e5b88b20de5fe53f4dd6b413
# Parent  b2371c9e05f5146767464db8504214ae2b77c25c
[PV-ON-HVM] Don't generate lots of spurious interrupts when using event
channel upcalls.

The issue here was that the Xen platform PCI interrupt is only updated
when you return from the hypervisor into guest context, and so remained
asserted for a short interval after the interrupt handler ran.  If
it happened that the first subsequent trap to the hypervisor was
for unmasking the 8259 interrupt again, the unmasking caused the interrupt
to be reinjected.  This caused an edge on the chaining interrupt from
the slave PIC to the master.  The platform interrupt on the slave
would then be cleared as we returned to the guest, and so you
eventually end up injecting an interrupt on the master chained
interrupt with nothing pending on the slave, which shows up as
a spurious interrupt in the guest.

Signed-off-by: Steven Smith <sos22@xxxxxxxxx>
 unmodified_drivers/linux-2.6/platform-pci/evtchn.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletion(-)

diff -r b2371c9e05f5 -r 79a40acadb41 
--- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c        Tue Oct 31 
11:31:34 2006 +0000
+++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c        Tue Oct 31 
11:38:55 2006 +0000
@@ -167,11 +167,17 @@ irqreturn_t evtchn_interrupt(int irq, vo
                        l2 = s->evtchn_pending[l1i] & ~s->evtchn_mask[l1i];
+       /* Make sure the hypervisor has a chance to notice that the
+          upcall_pending condition has been cleared, so that we don't
+          try and reinject the interrupt again. */
+        (void)HYPERVISOR_xen_version(0, NULL);
        return IRQ_HANDLED;
 void force_evtchn_callback(void)
-       evtchn_interrupt(0, NULL, NULL);
+        (void)HYPERVISOR_xen_version(0, NULL);

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] [PV-ON-HVM] Don't generate lots of spurious interrupts when using event, Xen patchbot-unstable <=