|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] Interrupt to CPU routing in HVM domains - again
Hi James,
We make the change and it did not help the perf issue; as result
Bart
> Subject: RE: [Xen-devel] Interrupt to CPU routing in HVM domains - again > Date: Sat, 6 Sep 2008 22:21:47 +1000 > From: james.harper@xxxxxxxxxxxxxxxx > To: bart_brooks@xxxxxxxxxxx; keir.fraser@xxxxxxxxxxxxx > CC: xen-devel@xxxxxxxxxxxxxxxxxxx > > Bart, > > 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( > else > { > *QueueMiniportHandleInterrupt = (BOOLEAN)!!xi->connected; > - *InterruptRecognized = TRUE; > + *InterruptRecognized = FALSE; > } > > //FUNCTION_EXIT(); > " > > 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. > > Thanks > > James >
See how Windows Mobile brings your life together—at home, work, or on the go. See Now
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|