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


RE: [Xen-devel] Interrupt to CPU routing in HVM domains - again

To: "bart brooks" <bart_brooks@xxxxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Interrupt to CPU routing in HVM domains - again
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 6 Sep 2008 22:21:47 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 06 Sep 2008 05:22:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4E7F460.1CD88%keir.fraser@xxxxxxxxxxxxx>
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: <20080905172848.GD22002@xxxxxxxxxxxxxxxxxxxxxxx> <C4E7F460.1CD88%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckP9PVhNA/0tnvoEd29dwAWy6hiGQAJL5gQ
Thread-topic: [Xen-devel] Interrupt to CPU routing in HVM domains - again

I'm pretty sure I've identified the problem. The fact that the output of
the debugging patch I sent you shows that sometimes one xennet isr is
logged and sometimes two are logged was a bit of a clue. I assume you
have two network adapters?

Please make the following change to xennet.c:

diff -r ea14db3ca6f2 xennet/xennet.c
--- a/xennet/xennet.c   Thu Sep 04 22:31:38 2008 +1000
+++ b/xennet/xennet.c   Sat Sep 06 22:14:36 2008 +1000
@@ -137,7 +137,7 @@ XenNet_InterruptIsr(
     *QueueMiniportHandleInterrupt = (BOOLEAN)!!xi->connected;
-    *InterruptRecognized = TRUE;
+    *InterruptRecognized = FALSE;


Xennet's isr was reporting that the interrupt was handled, which it was,
but xennet needs to report that it was not handled so that the next isr
in the chain is triggered. Your change to the isr in evtchn.c would have
caused spurious interrupts which had the side effect of ensuring that
the second xennet isr was triggered eventually.

I hope that makes sense. I'm too tired to re-read it to make sure :)

I'm not completely sure if it will work... I don't know how ndis will
react when we tell it that it needs to schedule a dpc even though we are
also telling it that the interrupt was not for us.

Let me know the outcome and I'll release an update if it works.



Xen-devel mailing list