Mapping large chunks of contiguous kernel space virtual memory

I am developing a driver for a PCI card which will have up to 1GB of flash memory. In the PCI driver, I am using MmMapIospace to map into kernel space virtual memory. This virtual memory address space, which needs to be contiguous, is used by user applications to access the flash.

This method works fine until I start mapping large chunks to reflect the flash density I have on the PCi card. On one machine, for example, I may be able to map upto 860MB, while on another, I am successful in mapping only upto 256MB of kernel space, but cannot get to 1GB.

My question is, what factors are limiting me from mapping the whole window of 1GB that I require for my largest flash devices? I know that only 2GB of kernel space is available, and that there a limited number of PTEs available, and this somehow plays into it. Is there a work around these conditions? Would using user space memory be more practical in this sense? If so, how might I do that?

Any suggestions woul be helpful.

Thanks,
Abu

The approach is flawed.
Just support read/write as if it were a disk, and get the application create a file mapping: CreateFileMapping on the device.

You really need to move to 64bit if you need anywhere near that much contiguous kernel added space.

  • S

-----Original Message-----
From: xxxxx@yahoo.com
Sent: Thursday, April 09, 2009 09:43
To: Windows System Software Devs Interest List
Subject: [ntdev] Mapping large chunks of contiguous kernel space virtual memory

I am developing a driver for a PCI card which will have up to 1GB of flash memory. In the PCI driver, I am using MmMapIospace to map into kernel space virtual memory. This virtual memory address space, which needs to be contiguous, is used by user applications to access the flash.

This method works fine until I start mapping large chunks to reflect the flash density I have on the PCi card. On one machine, for example, I may be able to map upto 860MB, while on another, I am successful in mapping only upto 256MB of kernel space, but cannot get to 1GB.

My question is, what factors are limiting me from mapping the whole window of 1GB that I require for my largest flash devices? I know that only 2GB of kernel space is available, and that there a limited number of PTEs available, and this somehow plays into it. Is there a work around these conditions? Would using user space memory be more practical in this sense? If so, how might I do that?

Any suggestions woul be helpful.

Thanks,
Abu


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

Ken,

Yes, that would be the better solution, but unfortunately, at this point I really can’t rely on the users of this application to have 64bit systems.

Is there a hard limit on how much I can get from the kernel in one mapping call?

Hi Alex,

for my application I need to be able to access the flash directly to send commands to it, query its registers etc. This will mostly be used for test and development, so I am not using any Windows or file system flash drivers, so using it as a disk or doing file I/O will not work for my intended use of it.

The problem is that you also can not rely on there being anything even close to 1GB of contiguous
address space on an x86_32 system, nor can you rely on any other hard limit. You have to design
this differently, as has already been described.

Good luck,

mm

xxxxx@yahoo.com wrote:

Ken,

Yes, that would be the better solution, but unfortunately, at this point I really can’t rely on the users of this application to have 64bit systems.

Is there a hard limit on how much I can get from the kernel in one mapping call?

Hi Alex,

for my application I need to be able to access the flash directly to send commands to it, query its registers etc. This will mostly be used for test and development, so I am not using any Windows or file system flash drivers, so using it as a disk or doing file I/O will not work for my intended use of it.

xxxxx@yahoo.com wrote:

Yes, that would be the better solution, but unfortunately, at this point I really can’t rely on the users of this application to have 64bit systems.

Is there a hard limit on how much I can get from the kernel in one mapping call?

Note that the limit is stronger than just “in one mapping call”. The
limit is TOTAL non-paged pool. Even if you broke it up into smaller
chunks, you couldn’t get that much kernel virtual space. The number of
page table entries assigned to kernel space is fixed.

for my application I need to be able to access the flash directly to send commands to it, query its registers etc. This will mostly be used for test and development, so I am not using any Windows or file system flash drivers, so using it as a disk or doing file I/O will not work for my intended use of it.

Sending commands and querying registers is easy, and only takes a few
pages. It’s the arbitrary random access that cannot be provided. You
will end up needing some kind of pseudo-paging scheme, where you map in
a chunk at a time.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> My question is, what factors are limiting me from mapping the whole window of 1GB that I require

my largest flash devices?

System address space and system PTE range.

Mapping 1GB to system PTEs is amazingly bad idea. Map them chunk-by-chunk instead, only the ones which are touched by the current request.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Thanks for all the input. I will need to go back to the drawing board and determine which option would work best for the application – obviously trying to corner 1GB is not practical.

Best Regards,
Abu

Hi All,

One more question comes to mind – is mapping the physical memory to USER space memory, come with the same limitations as mapping to kernel space?

I realize that I have to be careful and make sure only the application that owns the physical space should access it, but is expecting 1GB in the user space also asking too much?

Thanks,
Abu

xxxxx@yahoo.com wrote:

One more question comes to mind – is mapping the physical memory to USER space memory, come with the same limitations as mapping to kernel space?

I realize that I have to be careful and make sure only the application that owns the physical space should access it, but is expecting 1GB in the user space also asking too much?

Well, in this case, the application has a certain amount of control over
things. A user-mode process can create additional page table entries
(which cannot be done for non-paged pool), so the limit is not the
number of PTEs, but rather just finding a 1GB hole in the address space
below 2GB. As long as the process hasn’t loaded a boatload of DLLs with
preferred addresses all over the map, and has not allocated a whole
bunch of stuff from its heap, it should be able to find 1GB of address
space.

You can easily test this yourself by allocating 1GB using VirtualAlloc
with MEM_RESERVE. If that call succeeds, then your mapping would succeed.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> Well, in this case, the application has a certain amount of control over

things. A user-mode process can create additional page table entries
(which cannot be done for non-paged pool), so the limit is not the
number of PTEs, but rather just finding a 1GB hole in the address space
below 2GB. As long as the process hasn’t loaded a boatload of DLLs with
preferred addresses all over the map, and has not allocated a whole
bunch of stuff from its heap, it should be able to find 1GB of address
space.

You can easily test this yourself by allocating 1GB using VirtualAlloc
with MEM_RESERVE. If that call succeeds, then your mapping would succeed.

On a 32-bit system it’s still very fragile. The user address space is only
2 GB so all it takes is a single DLL that loads somewhere in the middle
of that, and suddenly you don’t have enough contiguous space anymore.


Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.

Whichever space, user or kernel, you are in, mapping large chunks as much as 1GB simply doesn’t sound like a good idea. Thanks for everybody’s input.

Best Regards,
Abu