[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?

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.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: 80000003, The exception code that was not handled
Arg2: 80531e95, The address that the exception occurred at
Arg3: f8ab95b4, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - <Unable to get error code text>

FAULTING_IP:
nt!IopVerifyDiskSignature+52
80531e95 cc int 3

TRAP_FRAME: f8ab95b4 -- (.trap 0xfffffffff8ab95b4)
ErrCode = 00000000
eax=00000002 ebx=f8ab96a4 ecx=8052cc7a edx=00000056 esi=8052cc7b edi=00000002
eip=80531e96 esp=f8ab9628 ebp=f8ab963c iopl=3         nv up ei pl nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000             efl=00003216
nt!IopVerifyDiskSignature+0x53:
80531e96 5b              pop     ebx
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: csrss.exe

IRP_ADDRESS: f8ab962c

LAST_CONTROL_TRANSFER: from 80531f0a to 80531e96

STACK_TEXT:
f8ab963c 80531f0a 00000002 8052cc7a 00000056 nt!IopVerifyDiskSignature+0x53
f8ab9658 8052b7c6 f8ab966c f8ab9674 8052cc1d nt!IopCompleteRequest+0x333
f8ab967c 8052cd92 8052cc7a f8ab96a4 00000002 nt!`string'+0x1a
f8ab9978 8052ce40 f8521e90 f8521bb0 000002f6 nt!FsRtlAddLargeMcbEntry+0x49c
f8ab9994 f8515802 f8521e90 f8521bb0 000002f6 nt!FsRtlSplitLargeMcb+0x9d
f8ab99ac f8516b7c f8521e90 f8521bb0 000002f6 xenpci!XenRtlAssert+0x32 [e:\driverstudio_prj\win-pvdrivers.hg\common\include\xen_windows.h @ 255]
f8ab9a78 f851661e 81eaa000 820779d0 814e1104 xenpci!XenPci_DOP_BuildScatterGatherListButDontExecute+0x52c [e:\driverstudio_prj\win-pvdrivers.hg\xenpci\xenpci_dma.c @ 758]
f8ab9aa8 f835a56e 81eaa000 820779d0 814e1104 xenpci!XenPci_DOP_BuildScatterGatherList+0x2e [e:\driverstudio_prj\win-pvdrivers.hg\xenpci\xenpci_dma.c @ 865]
f8ab9b00 f8341a08 00000000 00000001 81ff8688 NDIS!ndisMAllocSGList+0xd9
f8ab9b1c f822c528 81ff8688 814e2c20 814e2be8 NDIS!ndisMSendX+0x1a0
f8ab9b58 f8341985 81fb24e8 814e2c20 00000002 psched!MpSend+0x706
f8ab9b80 f80ead40 82006ac8 814e2c20 82095008 NDIS!ndisMSendX+0x1d6
f8ab9ba8 f80ea916 82095008 814e2c20 81f05788 tcpip!GetTCPHeaderAtDpcLevel+0x1f
f8ab9bd4 f80ea65a 82095008 f8ab9c02 00000001 tcpip!MdpAllocateAtDpcLevel+0xe7
f8ab9c04 f80ea79f 81eee500 09050980 814e2c20 tcpip!IPSendComplete+0x58
f8ab9d50 f80efdeb f8128898 814df1e8 814df180 tcpip!GetIPHdrBuffer+0x13
f8ab9dbc f80ef3a5 18b078c7 00000002 00000000 tcpip!GetConnID+0x1cb
f8ab9de0 f80e7a08 00000002 00000002 f8ab9e0c tcpip!TCPRcv+0x140e
f8ab9e14 f80e794f 00000002 f80e7901 f80e73d6 tcpip!ProcessTCBDelayQ+0xc4
f8ab9e20 f80e73d6 00000000 81ec52d8 f80e77f2 tcpip!TCPRcvComplete+0x20
f8ab9e2c f80e77f2 f8363d40 82095008 f8230b40 tcpip!IPRcvComplete+0x21
f8ab9e30 f8363d40 82095008 f8230b40 81fb24e8 tcpip!ARPRcvComplete+0x5
f8ab9e80 f822b01d 00ed5730 81fee178 00000003 NDIS!ethFilterDprIndicateReceivePacket+0x5a4
f8ab9e94 f822b1b4 81ec52d8 81fee178 00000003 psched!PsFlushReceiveQueue+0x15
f8ab9eb8 f822b5f9 81fb24f0 00000000 81ec52d8 psched!PsEnqueueReceivePacket+0xda
f8ab9ed0 f8363d40 81fb24e8 806e5422 ffdff9c0 psched!ClReceiveComplete+0x13
f8ab9f20 f87708b4 00ed5730 f8ab9f74 00000003 NDIS!ethFilterDprIndicateReceivePacket+0x5a4
f8ab9fcc 80545e6f 81e75b34 81e72000 00000000 xennet!XenNet_RxBufferCheck+0x604 [e:\driverstudio_prj\win-pvdrivers.hg\xennet\xennet_rx.c @ 811]
ffdff980 8055c4a4 f8aba000 0000391a 00000002 nt!WmiTraceEvent+0x3f8
ffdff984 f8aba000 0000391a 00000002 f8ab9fe4 nt!MiPageFileTraces+0x8c4
WARNING: Frame IP not in any known module. Following frames may be wrong.
ffdff988 00000000 00000002 f8ab9fe4 00000001 0xf8aba000

STACK_COMMAND: kb

FOLLOWUP_IP:
xenpci!XenRtlAssert+32 [e:\driverstudio_prj\win-pvdrivers.hg\common\include\xen_windows.h @ 255]
f8515802 5d pop ebp

FAULTING_SOURCE_CODE:
   251: XenRtlAssert(PCHAR expr, PCHAR filename, ULONG line_number)
   252: {
   253:   XenDbgPrint("Failed ASSERTion '%s' at %s:%d\n", expr, filename, line_number);
   254:   RtlAssert(expr, filename, line_number, NULL);
> 255: }
   256:
   257:
   258: #if 1
   259: #ifdef KdPrint
   260:   #undef KdPrint

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: xenpci!XenRtlAssert+32

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: xenpci

IMAGE_NAME: xenpci.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4af3a64f

FAILURE_BUCKET_ID: 0x8E_xenpci!XenRtlAssert+32

BUCKET_ID: 0x8E_xenpci!XenRtlAssert+32

Followup: MachineOwner
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

And then I unset the rx(XenNet_RxInit())/tx(XenNet_TxInit()) DPC to vCPU0, just let OS to assign the DPC, this problem vanishes.

Any ideas about the two problem ?

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

WARNING - OLD ARCHIVES

xen-devel

[Xen-devel] Several Issues about GPL Windows Driver