PhysicalAddress is simply a 64 bit variable that I am re-using. It contains
the 32 bit virtual address of the buffer pointer. So I cheated. It is NOT a
physical address.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Tzvetan Mikov [mailto:xxxxx@jupiter.com]
Sent: Thursday, October 25, 2001 3:09 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?
There are two things that I don’t understand in your suggestion:
fDx->RdmaMdl = MmCreateMdl(NULL, // Create and Initialize an
MDL
(PVOID)physicalAddress.LowPart,
RDMA_BUFFER_SIZE);
You are passing a physical address to MmCreateMdl? Its parameter must be be
a virtual address.
fDx->RdmaBuffer = MmMapLockedPages(fDx->RdmaMdl, UserMode);
As I already said, MmMapLockedPages() asserts under the checked build of W2K
if the address is outside of the system RAM. So, have you tried this on the
checked build? How do you prevent the assertion failure??
-tzvetan
----- Original Message -----
From: “Gary Little”
To: “NT Developers Interest List”
Sent: Wednesday, October 24, 2001 4:48 PM
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?
> 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: xxxxx@jupiter.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
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