DMA memory allocation in vista drivers

NTDEV
1

Hi folks,

please help me in clarifying some doubts regarding the following call

MmAllocateContiguousMemorySpecifyCache : which is used to allocate io
memory for drivers.

1)how the allocated memory in host will beccessed by the DMA controller
(considering the case of a bus master device).
i would like to know whether a logical address will be used or direct phy
addresses?

2)why calling MmAllocateContiguousMemorySpecifyCache followed by
MmGetPhysicalAddress is not a good practice
for all platforms.

3)which call is better suited for aloocating 2k size chunk of packets
MmAllocateContiguousMemorySpecifyCache or NdisMAllocateSharedMemory

Thanks in advance…

2

Unless you’re an NDIS driver, you can’t use NdisMAllocateSharedMemory.

MmAllocateContiguousMemorySpecifyCache with MmGetPhysicalAddress
probably is good enough on most normal platforms, but why do this
when there is IoGetDmaAdapter and AllocateCommonBuffer.

KMDF has it’s own “DMA Enabler” thing (with WdfCommonBufferCreate)
similar to “DMA Adapter” or WDM.

–PA

joyjit mullick wrote:

Hi folks,

please help me in clarifying some doubts regarding the following call

MmAllocateContiguousMemorySpecifyCache : which is used to allocate io
memory for drivers.

1)how the allocated memory in host will beccessed by the DMA controller
(considering the case of a bus master device).
i would like to know whether a logical address will be used or direct
phy addresses?

2)why calling MmAllocateContiguousMemorySpecifyCache followed by
MmGetPhysicalAddress is not a good practice
for all platforms.

3)which call is better suited for aloocating 2k size chunk of packets
MmAllocateContiguousMemorySpecifyCache or NdisMAllocateSharedMemory

Thanks in advance…

3

joyjit mullick wrote:

please help me in clarifying some doubts regarding the following call

MmAllocateContiguousMemorySpecifyCache : which is used to allocate io
memory for drivers.

That description is a bit terse. It is used to allocate common buffers
for devices that do non-scatter/gather DMA.

1)how the allocated memory in host will beccessed by the DMA
controller (considering the case of a bus master device).
i would like to know whether a logical address will be used or direct
phy addresses?

The correct approach is to let the kernel DMA abstraction
(IoGetDmaAdapter) worry about this. The device eventually needs to be
told the bus physical address.

2)why calling MmAllocateContiguousMemorySpecifyCache followed by
MmGetPhysicalAddress is not a good practice
for all platforms.

I’ll give you an example. Let’s say you have a bus-mastering PCI device
that only handles 32-bit physical addresses, as many do. Let’s say
you’re running on a Server 2003 system with 16GB of RAM. Statistically,
it’s quite likely that MmAllocateContiguousMemorySpecifyCache is going
to return you memory with a physical address beyond the 4GB mark. Your
hardware can’t handle that. You’re stuck.

IoGetDmaAdapter, on the other hand, will do whatever needs to be done,
by allocating “bounce buffers” within the first 4GB of physical RAM, and
making sure that the physical addresses you get are all within the range
for your device.

3)which call is better suited for aloocating 2k size chunk of packets
MmAllocateContiguousMemorySpecifyCache or NdisMAllocateSharedMemory

Pavel already addressed this. However, I’d like to add one additional
note. There is no need to use MmAllocateContiguousMemorySpecifyCache
for a buffer this small. If you allocate 4k bytes, you will get one
complete page of memory, and memory within a single page is always
contiguous.

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

4

MmAllocateContiguousMemorySpecifyCache provides high, low, and boundary
parameters that allow you to select where the memory is located.
AllocateCommonBuffer is just a front end to this with the logical
address abstraction tossed in and less control over the memory cache
type.

-----Original Message-----

I’ll give you an example. Let’s say you have a bus-mastering PCI device
that only handles 32-bit physical addresses, as many do. Let’s say
you’re running on a Server 2003 system with 16GB of RAM. Statistically,
it’s quite likely that MmAllocateContiguousMemorySpecifyCache is going
to return you memory with a physical address beyond the 4GB mark. Your
hardware can’t handle that. You’re stuck.

IoGetDmaAdapter, on the other hand, will do whatever needs to be done,
by allocating “bounce buffers” within the first 4GB of physical RAM, and
making sure that the physical addresses you get are all within the range
for your device.

5

Tim,

thanks for the clear and very precise clarification.i have a questions now
regarding IoGetDmaAdapter

  1. can it be called from a ndis6.0 driver?or is there any ndis wrapper e.g
    ndismxx

On Thu, Sep 11, 2008 at 10:55 PM, Tim Roberts wrote:

> joyjit mullick wrote:
> >
> > please help me in clarifying some doubts regarding the following call
> >
> > MmAllocateContiguousMemorySpecifyCache : which is used to allocate io
> > memory for drivers.
>
> That description is a bit terse. It is used to allocate common buffers
> for devices that do non-scatter/gather DMA.
>
>
> > 1)how the allocated memory in host will beccessed by the DMA
> > controller (considering the case of a bus master device).
> > i would like to know whether a logical address will be used or direct
> > phy addresses?
>
> The correct approach is to let the kernel DMA abstraction
> (IoGetDmaAdapter) worry about this. The device eventually needs to be
> told the bus physical address.
>
>
> > 2)why calling MmAllocateContiguousMemorySpecifyCache followed by
> > MmGetPhysicalAddress is not a good practice
> > for all platforms.
>
> I’ll give you an example. Let’s say you have a bus-mastering PCI device
> that only handles 32-bit physical addresses, as many do. Let’s say
> you’re running on a Server 2003 system with 16GB of RAM. Statistically,
> it’s quite likely that MmAllocateContiguousMemorySpecifyCache is going
> to return you memory with a physical address beyond the 4GB mark. Your
> hardware can’t handle that. You’re stuck.
>
> IoGetDmaAdapter, on the other hand, will do whatever needs to be done,
> by allocating “bounce buffers” within the first 4GB of physical RAM, and
> making sure that the physical addresses you get are all within the range
> for your device.
>
>
> > 3)which call is better suited for aloocating 2k size chunk of packets
> > MmAllocateContiguousMemorySpecifyCache or NdisMAllocateSharedMemory
>
> Pavel already addressed this. However, I’d like to add one additional
> note. There is no need to use MmAllocateContiguousMemorySpecifyCache
> for a buffer this small. If you allocate 4k bytes, you will get one
> complete page of memory, and memory within a single page is always
> contiguous.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>

6

“Tim Roberts” wrote in message news:xxxxx@ntdev…
…
> I’ll give you an example. Let’s say you have a bus-mastering PCI device
> that only handles 32-bit physical addresses, as many do. Let’s say
> you’re running on a Server 2003 system with 16GB of RAM. Statistically,
> it’s quite likely that MmAllocateContiguousMemorySpecifyCache is going
> to return you memory with a physical address beyond the 4GB mark. Your
> hardware can’t handle that. You’re stuck.
>
> IoGetDmaAdapter, on the other hand, will do whatever needs to be done,
> by allocating “bounce buffers” within the first 4GB of physical RAM, and
> making sure that the physical addresses you get are all within the range
> for your device.

In this case, will IOMMU allow to map system memory above 4GB directly
to the device, without bounce buffers?

–PA

7

Pavel A. wrote:

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> …
>> I’ll give you an example. Let’s say you have a bus-mastering PCI device
>> that only handles 32-bit physical addresses, as many do. Let’s say
>> you’re running on a Server 2003 system with 16GB of RAM. Statistically,
>> it’s quite likely that MmAllocateContiguousMemorySpecifyCache is going
>> to return you memory with a physical address beyond the 4GB mark. Your
>> hardware can’t handle that. You’re stuck.
>>
>> IoGetDmaAdapter, on the other hand, will do whatever needs to be done,
>> by allocating “bounce buffers” within the first 4GB of physical RAM, and
>> making sure that the physical addresses you get are all within the range
>> for your device.
>
> In this case, will IOMMU allow to map system memory above 4GB directly
> to the device, without bounce buffers?

I’m not sure I understand the question. On all current x86 and x64
machines, the “IOMMU” doesn’t do any remapping. It would be possible to
create a chipset that did this, but I don’t know of any that do so today.

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

8

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Pavel A. wrote:
>> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>> …
>>> I’ll give you an example. Let’s say you have a bus-mastering PCI device
>>> that only handles 32-bit physical addresses, as many do. Let’s say
>>> you’re running on a Server 2003 system with 16GB of RAM. Statistically,
>>> it’s quite likely that MmAllocateContiguousMemorySpecifyCache is going
>>> to return you memory with a physical address beyond the 4GB mark. Your
>>> hardware can’t handle that. You’re stuck.
>>>
>>> IoGetDmaAdapter, on the other hand, will do whatever needs to be done,
>>> by allocating “bounce buffers” within the first 4GB of physical RAM, and
>>> making sure that the physical addresses you get are all within the range
>>> for your device.
>>
>> In this case, will IOMMU allow to map system memory above 4GB directly
>> to the device, without bounce buffers?
>
> I’m not sure I understand the question. On all current x86 and x64
> machines, the “IOMMU” doesn’t do any remapping. It would be possible to
> create a chipset that did this, but I don’t know of any that do so today.

Yes, Tim, this is what I’d like to know: if the emerging IOMMU solutions
(besides of all VT and security things) would allow direct mapping
of device that supports only 32-bit bus relative address,
maybe we could save some silicon cost without performance penalty.

–PA