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] 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
> 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
> line 756 gref = (grant_ref_t)GntTbl_GrantAccess(xpdd, 0, (ULONG)pfn,
> 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 ==
> 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



Xen-devel mailing list

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