Here is my solution … this is on a common buffer allocated via DMA
operations.
fDx->RdmaMdl = MmCreateMdl(NULL, // Create and Initialize an
MDL
(PVOID)physicalAddress.LowPart,
RDMA_BUFFER_SIZE);
MmBuildMdlForNonPagedPool(fDx->RdmaMdl);
fDx->RdmaBuffer = MmMapLockedPages(fDx->RdmaMdl, UserMode);
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Tzvetan Mikov [mailto:xxxxx@jupiter.com]
Sent: Wednesday, October 24, 2001 4:31 PM
To: NT Developers Interest List
Subject: [ntdev] No right way to share PCI device memory with user mode?
Hi,
I’ve already asked this on comp.os.ms-windows.programmer.nt.kernlel-mode but
after a total lack of responses I am trying here in a last desperate
attempt.
My question should be simple: what is supposed to be right way
of sharing PCI device memory with an user mode application under W2K? I know
this has been asked lots of times. My search in Google found dozens
(if not hundreds!) of posts about this, but unfortunately not even one
sensible answer. Well, it is possible that I missed that one answer, in
which case I apologize and will be grateful for a reference to it.
Let me give you the information I have so far. The MSDN gives two possible
solutions. Unfortunately both of them seem to have problems: one aserts in
the checked build, the other is rumoured to be too slow.
Solution A (from Q189327 and Q191840):
Use MmMapIoSpace, IoAllocateMdl, MmBuildMdlForNonPagedPool,
MmMapLockedPages(UserMode).
This would have been my preferred solution since it also creates a virtual
address usable outside of the calling process context (the result of
MmMapIoSpace) and uses calls that are well understood and documented.
Unfortunately under the checked build of W2K (SP1), MmMapLockedPages asserts
with something like “ASSERT( Page > MmHighestPhysicalPage )” when the
address is in PCI device memory (as opposed to RAM).
Well, I know that this assertion is not so bad, it can be ignored (or even
better - patch the kernel at runtime not to generate it at all), but we use
W2K checked build for production testing and such behavior is unacceptable.
Solution B (from Q189327 and the MAPMEM sample from the NT 4.0 DDK):
Use ZwOpenSection(“\Device\PhysicalMemory”) and ZwMapViewOfSection. This
code seems a little more scary at first since ZwOpenSection and
ZwMapViewOfSection are not that well documented. However after a little
digging in the Platform SDK all parameters can be deciphered.
The problem here is the reports from several different people claiming that
this solution yields very bad performance when accessing the memory from
user mode.
I personally haven’t still measured the speed difference between Solution A
and B and for me currently Solution B is good enough since for my particular
application speed is not such of an issue (yet?). However I am surprised
that something so important and supposedly simple seems to have no
well-known solution.
-tzvetan
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com