Hi - I am trying to do something which I am sure is not too unusual but I can’t find any semi-authoritive examples on how to do it and would really value some guidance. I am trying to expose physical memory to user mode with the aid of the MAXMEM boot.ini flag (yawn/ yawn I hear you say; but please read on). The reason I need to do this is because my client needs to replace an RTX embedded driver with a WDM driver. The hardware and software on the box are totally vendor specified so I think this a pretty legitimate reason for using this shady technique. MAXMEM works “out of the box” with RTX and the user mode code that uses this memory must remain unchanged hence the requirement. I have a solution that “seems to work” (ho ho) but I am deeply nervous about it because I had to brew it myself; hence this mail. I have used the MmMapIoSpace(KnownPhysicalAddressMemoryBecauseWeUsedMAXMEM) approach et cetera.
I have been following this thread http://www.osronline.com/showThread.CFM?link=129071 and have a specific question about one of the comments:-
Here you have virtual address for using in User space, but before you pass it
up, first unmap space you taken.
MmUnmapIoSpace(IoMapedBaseVa,size);
Is this correct? I have to unmap the kernel memory before returning the virtual address to user mode? Why is that?
Does anyone know of an example of passing physical memory to user mode with MAXMEM?
Thanks,
Ben
xxxxx@gmail.com wrote:
Hi - I am trying to do something which I am sure is not too unusual but I can’t find any semi-authoritive examples on how to do it and would really value some guidance. I am trying to expose physical memory to user mode with the aid of the MAXMEM boot.ini flag … I have a solution that “seems to work” (ho ho) but I am deeply nervous about it because I had to brew it myself; hence this mail. I have used the MmMapIoSpace(KnownPhysicalAddressMemoryBecauseWeUsedMAXMEM) approach et cetera.
I have been following this thread http://www.osronline.com/showThread.CFM?link=129071 and have a specific question about one of the comments:
> Here you have virtual address for using in User space, but before you pass it
> up, first unmap space you taken.
> MmUnmapIoSpace(IoMapedBaseVa,size);
Is this correct? I have to unmap the kernel memory before returning the virtual address to user mode? Why is that?
It is not required. I believe he was doing that merely to free up the
kernel virtual address space. If you don’t need to access the memory
from your kernel driver, that’s a fine idea. Kernel virtual space is a
limited resource.
Does anyone know of an example of passing physical memory to user mode with MAXMEM?
Not with MAXMEM, but in this case your physical memory is exactly like
the memory BAR on a PCI device. It’s a physical address range that the
operating system essentially does not know about. Treat it like I/O memory.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
With the caveat that mapping physical memory above MAXMEM this way causes the Checked Build of Windows to crash. Or, at least it did when I last tried this… which was many moons ago…
Peter
OSR
> With the caveat that mapping physical memory above MAXMEM this
way causes the Checked Build of Windows to crash. Or, at least
it did when I last tried this… which was many moons ago…
This should work without any crashes or asserts, even on checked builds.
(Whether or not this is a good design is a separate question…)
thanks folks; now I wonder whether the checked build behaviour has any connection to the driver verifier assertion I am seeing (“MmMapIoSpace called without locking MDL pages”). A question posed (but not answered (as it is obviously an inferior list 
)) here http://www.winvistatips.com/driver-verifier-says-mmmapiospace-called-without-locking-mdl-pages-fix-t192904.html. Verifier grumbles after the call to mmMapIoSpace(), before I have had a chance to do any locking; is this what you would expect?
Ben
Verifier thinks the physical address you’re trying to map is within the OS-visible portion of the RAM, and is not locked down.
You can check the value of nt!MmHighestPhysicalPage and compare it to the address verifier is complaining about.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, June 30, 2011 9:05 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] maxmem - physical memory allocation
thanks folks; now I wonder whether the checked build behaviour has any connection to the driver verifier assertion I am seeing (“MmMapIoSpace called without locking MDL pages”). A question posed (but not answered (as it is obviously an inferior list )) here http://www.winvistatips.com/driver-verifier-says-mmmapiospace-called-without-locking-mdl-pages-fix-t192904.html. Verifier grumbles after the call to mmMapIoSpace(), before I have had a chance to do any locking; is this what you would expect?
Ben
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer