http://bugs.winehq.org/show_bug.cgi?id=10264
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #33 from Anastasius Focht focht@gmx.net 2009-06-19 06:04:06 --- Hello,
it will be a long way until TAGES drivers really begin to talk. This requires a considerable amount of additional infrastructure and rethought of current design. Many ntoskrnl API are just stubs - doing nothing.
One of the main problems is that Wine has to emulate the concept of "kernel" address space vs. user address space mappings somehow (out-of-process context).
This specific failure is due to IoAllocateMdl() being a stub:
--- snip --- 0009:Call KERNEL32.CreateFileW(0032c61c L"\\.\lirsgt",c0000000,00000000,00000000,00000003,40000000,00000000) ret=0040108f 0009:Ret KERNEL32.CreateFileW() retval=00000038 ret=0040108f 0009:Call KERNEL32.DeviceIoControl(00000038,0022e013,0032c840,00000000,0032c840,00000000,0032c858,00000000) ret=00401c9a ... 001a:trace:ntoskrnl:process_ioctl ioctl 22e013 device 0x11d740 in_size 0 out_size 0 ... 001a:Call driver dispatch 0x652140 (device=0x11d740,irp=0x64e750) 001a:Call ntoskrnl.exe.IoAllocateMdl(0011dd20,00000005,00000000,00000000,00000000) ret=006516bd 001a:fixme:ntoskrnl:IoAllocateMdl stub: 0x11dd20, 5, 0, 0, (nil) 001a:Ret ntoskrnl.exe.IoAllocateMdl() retval=00000000 ret=006516bd 001a:trace:ntoskrnl:__regs_IofCompleteRequest 0x64e750 0 ... 001a:Ret driver dispatch 0x652140 (device=0x11d740,irp=0x64e750) retval=c000009a ... 0009:Ret KERNEL32.DeviceIoControl() retval=00000000 ret=00401c9a --- snip ---
The kernel driver receives a "usermode" pointer within a struct as input to DeviceIoControl. To access the data from user pointer location, the kernel driver has to map it into "kernel" space context.
It wouldn't be necessary to build a MDL if the kernel driver is the top level driver invoked from the calling process context (via DeviceIoControl) which can be read/written to directly -> ProbeForRead/Write, so I assume they went safe way considering out-of-process context.
Within driver dispatch handler it basically does:
mdl = IoAllocateMdl(userBuf, userBufLen, FALSE, FALSE, NULL); ... MmProbeAndLockPages(mdl, UserMode, IoWriteAccess); ...
See:
http://msdn.microsoft.com/en-us/library/aa490866.aspx (IoAllocateMdl) http://msdn.microsoft.com/en-us/library/aa489506.aspx (Using MDLs)
If you return an MDL, you also need a MmProbeAndLockPages() stub because the driver tries to lock the virtual to physical mapping of the buffer. After that you need MmMapLockedPagesSpecifyCache() because the driver wants the user virtual address for the MDL...
To be honest: I wouldn't start with that stuff until there is proper infrastructure and concept in Wine, supporting such address space manipulations (e.g. "fake" user space vm address space mappings using special buffers which trigger proper process memory reads/writes for the target process when being accessed from kernel driver).
Regards