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

RE: [Xen-devel] Several Issues about GPL Windows Driver

To: "Huibin QIAN" <qianhb@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Several Issues about GPL Windows Driver
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Fri, 13 Nov 2009 20:52:18 +1100
Cc: q00147403@xxxxxxxxxxxxxxxxxxxx, c47994@xxxxxxxxxxxxx
Delivery-date: Fri, 13 Nov 2009 01:53:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <001001ca642c$53b6fbc0$d738a60a@xxxxxxxxxxxxxxxx>
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: <001001ca642c$53b6fbc0$d738a60a@xxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpkLHpJDnk5slXmTE2zIm9OZF3kjAAD0j4g
Thread-topic: [Xen-devel] Several Issues about GPL Windows Driver
> Hey All
> 
> Several Issuses I am NOT clear about GPL Windows Driver
> 
> 1. In xennet, GPL Win Driver set the
rx(XenNet_RxInit())/tx(XenNet_TxInit())
> DPC to vCPU0 using KeSetTargetProcessorDpc().
> My quetions why we should do in this way, Any problem if I unset the
rx/tx DPC
> to vCPU0, just let OS to assign DPC to which vCPUs?

NDIS Dpc's only run on CPU 0. I think you'll find a lot of lock
contention if you make the DPC's run on all CPU's.

> 
> 2. In xenpci, XenPci_DOP_BuildScatterGatherListButDontExecute() line
756,
> line 756 gref = (grant_ref_t)GntTbl_GrantAccess(xpdd, 0, (ULONG)pfn,
FALSE,
> INVALID_GRANT_REF);
> line 757 ASSERT(gref != INVALID_GRANT_REF);
> if there's NOT eough gref, there should be a crash, why NOT deal with
it like
> the way XenScsi_PutSrbOnRing() in xenscsi.c?
> line 614     if (shadow->req.seg[shadow->req.nr_segments].gref ==
0x0FFFFFFF)
> line 615    {
> line 616      return; /* better than crashing... */
> line 617    }
> At least, this will NOT crash the OS.
> Because when I use iperf do a test between two DomU (WINDOWS XP SP2)
on some
> Dom0.
> A:One DomU as iperf client
> iperf -c $(IP_SERVER) -i 1 -w 64k  -l 1 -t 300
> another one as iperf server:
> B:iperf -s -P 1 -i 1 -w 64k  -l 1
> 
> In this way, I set iperf buffer length is 1 bytes.
> 
> The Client crashes everytime!!!!
> The callstack of Client Windows is as following.
> 

You posted that previously. Do you have a Windows 2003 setup you can
test with too? That way I could reproduce it and know if it will be
fixed.

James

 

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

<Prev in Thread] Current Thread [Next in Thread>