Is the physical address of a buffer in non paged pool constant?

If I find out the physical address of one of my buffers in non paged pool, can I assume it
won’t change?

I’m fairly sure that up to W2K3 the answer is “yes”. I wondered if was still true for later OS offerings.

I also tried to see if the behavour I want (which is that non paged pool does not move around
in physical memory) is guaranteed anywhere, but I didn’t find anything.

Don

Why do you want to know this? If this were a guarantee, what would you
do with this information?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Monday, December 18, 2006 3:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Is the physical address of a buffer in non paged pool
constant?

If I find out the physical address of one of my buffers in non paged
pool, can I assume it
won’t change?

I’m fairly sure that up to W2K3 the answer is “yes”. I wondered if was
still true for later OS offerings.

I also tried to see if the behavour I want (which is that non paged pool
does not move around
in physical memory) is guaranteed anywhere, but I didn’t find anything.

Don


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I have a DMA engine which pulls in a block of descriptors (to part of the
SG list for the user’s buffer). The last entry in the block is the next
block of descriptors - thus chaining the whole SG list. So the DMA engine
DMA’s it’s way down the list.

I don’t really want to establish the physical addresses for my descriptor
blocks on every transfer. I’d rather do it just once.

If there is no guarantee, maybe I’d have to look at allocating lumps of
physically contiguous memory for the descriptor blocks to minimise the
overheads. But since the descriptor blocks might be quite large (500KB or so)
and I have six of these devices (or possibly twelve or eighteen) per system
I’m keen not to allocate so much physically contiguous memory.

Don

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: 19 December 2006 00:04
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is the physical address of a buffer in
non paged pool constant?

Why do you want to know this? If this were a guarantee, what
would you do with this information?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Monday, December 18, 2006 3:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Is the physical address of a buffer in non paged pool
constant?

If I find out the physical address of one of my buffers in non paged
pool, can I assume it won’t change?

The answer is that there is no such guarantee in the long run, and you
probably won’t get a definite “stop doing this” if some day the physical
address could change.

Hot-Plug memory is one of the futuristic things that I suspect could
blow you out of the water - if we know that there aren’t any active DMA
transactions with memory on a particular memory module we could relocate
its contents and let it be removed.

Presumably you own the memory holding the descriptors. What if you
allocated them using MmAllocateMdlPages(), prepared them for DMA and
then got an MDL for the scatter gather list and mapped that to get your
virtual access.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Monday, December 18, 2006 4:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is the physical address of a buffer in non paged
pool constant?

I have a DMA engine which pulls in a block of descriptors (to part of
the
SG list for the user’s buffer). The last entry in the block is the next
block of descriptors - thus chaining the whole SG list. So the DMA
engine
DMA’s it’s way down the list.

I don’t really want to establish the physical addresses for my
descriptor
blocks on every transfer. I’d rather do it just once.

If there is no guarantee, maybe I’d have to look at allocating lumps of
physically contiguous memory for the descriptor blocks to minimise the
overheads. But since the descriptor blocks might be quite large (500KB
or so)
and I have six of these devices (or possibly twelve or eighteen) per
system
I’m keen not to allocate so much physically contiguous memory.

Don

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: 19 December 2006 00:04
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is the physical address of a buffer in
non paged pool constant?

Why do you want to know this? If this were a guarantee, what
would you do with this information?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Monday, December 18, 2006 3:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Is the physical address of a buffer in non paged pool
constant?

If I find out the physical address of one of my buffers in non paged
pool, can I assume it won’t change?


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Comments embedded

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: 19 December 2006 00:44
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is the physical address of a buffer in
non paged pool constant?

The answer is that there is no such guarantee in the long run, and you
probably won’t get a definite “stop doing this” if some day
the physical address could change.

Hot-Plug memory is one of the futuristic things that I suspect could
blow you out of the water - if we know that there aren’t any
active DMA transactions with memory on a particular memory module we
could relocate its contents and let it be removed.

This is a good hint. Thanks.

Presumably you own the memory holding the descriptors. What if you
allocated them using MmAllocateMdlPages(),

I can’t find “MmAllocateMdlPages” in 3790.1830 - do you
mean “MmAllocatePagesForMdl”?

prepared them for DMA and then got an MDL for the scatter gather list
and mapped that to get your virtual access.

This is more or less what I was thinking about doing (except I was going to
use the KMDF equivalent mechanism). What I’d missed was that setting up
a dma transfer on the descriptors themselves, and not completing it, would
probably inhibit any movement of the memory in a future scenario that might
alter the physical address of non paged pool.

Don

Virtualization is another reason that the physical addresses can change.
Please use the DMA APIs properly.

Assuming that the processor-relative physical address of the buffer is the
same as the device-relative physical address (what the DDK calls the DMA
Logical Address) is only going to get you into trouble.

  • Jake Oshins
    Windows Kernel Team

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
The answer is that there is no such guarantee in the long run, and you
probably won’t get a definite “stop doing this” if some day the physical
address could change.

Hot-Plug memory is one of the futuristic things that I suspect could
blow you out of the water - if we know that there aren’t any active DMA
transactions with memory on a particular memory module we could relocate
its contents and let it be removed.

Presumably you own the memory holding the descriptors. What if you
allocated them using MmAllocateMdlPages(), prepared them for DMA and
then got an MDL for the scatter gather list and mapped that to get your
virtual access.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Monday, December 18, 2006 4:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is the physical address of a buffer in non paged
pool constant?

I have a DMA engine which pulls in a block of descriptors (to part of
the
SG list for the user’s buffer). The last entry in the block is the next
block of descriptors - thus chaining the whole SG list. So the DMA
engine
DMA’s it’s way down the list.

I don’t really want to establish the physical addresses for my
descriptor
blocks on every transfer. I’d rather do it just once.

If there is no guarantee, maybe I’d have to look at allocating lumps of
physically contiguous memory for the descriptor blocks to minimise the
overheads. But since the descriptor blocks might be quite large (500KB
or so)
and I have six of these devices (or possibly twelve or eighteen) per
system
I’m keen not to allocate so much physically contiguous memory.

Don

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: 19 December 2006 00:04
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Is the physical address of a buffer in
> non paged pool constant?
>
>
> Why do you want to know this? If this were a guarantee, what
> would you do with this information?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
> Sent: Monday, December 18, 2006 3:46 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Is the physical address of a buffer in non paged pool
> constant?
>
> If I find out the physical address of one of my buffers in non paged
> pool, can I assume it won’t change?
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I am planning to “use the DMA API properly” - the question was designed to find out what “properly” means. I.e once I have the proper device relative physical addresses of my descriptors in non paged pool, can I assume they remain constant? It would seem the answer is no.

Jake: I don’t believe I’m making the assumption (processor relative PhysAddr = device relative PhysAdr) that you think I am, but feel free to point out why you think so.

Given there is a possibility that the physical addresses of my dma descriptors may change, my plan now is, when my driver initialises, to start a “fake” DMA transaction of the descriptors to establish the correct device relative addresses to use and (thanks to Peter for the hint) never complete it. Because the system thinks dma is taking place on the descriptors it will never move them, so I can safely use the addresses in the descriptor fields that DMA in the next block of descriptors. This will tie up a dma enabler object permanently, but I have several.

Or does this plan count as “not using the DMA API properly”? If so why?

Regards

Don

That’s fine. But you should look at the common buffer DMA APIs. They are
much closer to what you want.

  • Jake

wrote in message news:xxxxx@ntdev…
>I am planning to “use the DMA API properly” - the question was designed to
>find out what “properly” means. I.e once I have the proper device relative
>physical addresses of my descriptors in non paged pool, can I assume they
>remain constant? It would seem the answer is no.
>
> Jake: I don’t believe I’m making the assumption (processor relative
> PhysAddr = device relative PhysAdr) that you think I am, but feel free to
> point out why you think so.
>
> Given there is a possibility that the physical addresses of my dma
> descriptors may change, my plan now is, when my driver initialises, to
> start a “fake” DMA transaction of the descriptors to establish the correct
> device relative addresses to use and (thanks to Peter for the hint) never
> complete it. Because the system thinks dma is taking place on the
> descriptors it will never move them, so I can safely use the addresses in
> the descriptor fields that DMA in the next block of descriptors. This will
> tie up a dma enabler object permanently, but I have several.
>
> Or does this plan count as “not using the DMA API properly”? If so why?
>
> Regards
>
> Don
>

Thanks Jake, I’ll take another look. I was under the impression that common buffer dma wasn’t very happy about large common buffers (for instance 3790.1830 says IN ITALICS “use common buffer economically”). With my current design, I would need six (or twelve, or eighteen) common buffers of 256KB each. I may be able to refactor things to share the descriptors between devices but, whatever I do, it will still be quite a large common buffer to support the transfer sizes that I need.

My descriptors don’t have to be physically contiguous (although I agree it’s easier for me if they are) so I was trying to put less strain on the system by just using non paged pool.

Don

Oh, the DDK Docs are just being all “Motherhood and Apple Pie” here, and thus OVER emphasizing to a knowledgeable reader what’s likely intended as general guidance (“don’t tie-up lots of memory, folks!”).

AllocateCommonBuffer is, in fact, gives the system more flexibility in allocating the memory than forcing the system to allocate from non-paged pool.

As Peter Wieland suggested, MY personal go-to DDI for allocating large chunks of non-paged memory is MmAllocatePagesForMdl. Of course, you’ll need to feed this into the appropriate DMA DDIs for your use.

HTH,

Peter
OSR