Hello,
Does anyone know how to access the OS’s Highest Physical Address through an application?
I’m aware you can go to HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\System Resources\Physical Memory.Translated
and double click on .Translated and retrieve this information but I’d like to be able to access this info through my app. I’m not entirely sure how to decipher the .Translated value to parse out the Physical Addresss and length.
Thanks!
Why do you need to do that? Which problem are you trying to solve?
Have a nice day
GV
–
Gianluca Varenni, Windows DDK MVP
CACE Technologies
http://www.cacetech.com
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, December 05, 2007 11:31 AM
Subject: [ntdev] Accessing OS’s highest Physical memory
> Hello,
>
> Does anyone know how to access the OS’s Highest Physical Address through
> an application?
> I’m aware you can go to HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\System
> Resources\Physical Memory.Translated
>
> and double click on .Translated and retrieve this information but I’d like
> to be able to access this info through my app. I’m not entirely sure how
> to decipher the .Translated value to parse out the Physical Addresss and
> length.
>
> Thanks!
>
> —
> 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
Hi,
I’m trying to reserve a portion of physical memory for DMA transfers. I’m doing this through my application. In order to do this I need the OS’s highest Physical address. So far I haven’t found a way to retrieve this and decipher the .Translated value.
Thanks.
I don’t believe that there is a direct way to determine this other than
that registry key, assuming that it is unaltered, or calling
MmGetPhysicalMemoryRanges, which I believe is undocumented, and returns
the same information that is used to create those registry values. It
goes something like this:
NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (VOID);
struct PHYSICAL_MEMORY_RANGE
{
PHYSICAL_ADDRESS BaseAddress;
LARGE_INTEGER NumberOfBytes;
};
It returns an array of these structures, with a {0, 0} sentinel. I have
never really examined its output closely, or really used this function
for anything other than simple experimentation, so it may or may not be
accurate, and I have no idea of how you would go about freeing the
memory returned, except to say that it is probably best not to do so,
and live with the small leak, unless you have other information.
Of course, you could and probably should just read the registry key in
code. When you say ‘app,’ do you mean user mode? If so, then forget
everything I just said. My guess would be that the entry is effectively
a CM_RESOURCE_LIST. That is just a guess.
Good luck,
mm
xxxxx@yahoo.com wrote:
Hello,
Does anyone know how to access the OS’s Highest Physical Address through an application?
I’m aware you can go to HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\System Resources\Physical Memory.Translatedand double click on .Translated and retrieve this information but I’d like to be able to access this info through my app. I’m not entirely sure how to decipher the .Translated value to parse out the Physical Addresss and length.
Thanks!
Why do you need the highest specifically? It seems a little
unreasonable, as it may be used for something else.
mm
xxxxx@yahoo.com wrote:
Hi,
I’m trying to reserve a portion of physical memory for DMA transfers. I’m doing this through my application. In order to do this I need the OS’s highest Physical address. So far I haven’t found a way to retrieve this and decipher the .Translated value.
Thanks.
I am a bit confused.
What do you mean by “reserving a portion of physical memory for DMA from my
application”? Maybe I’m missing something here.
This is something that a driver would do i.e. allocating the memory for DMA.
If you need a big chunk of DMAable memory, you probably want to do that as
soon the driver gets loaded into memory (i.e. at boot time) when there are
good chances that physical memory is not too fragmented.
Have a nice day
GV
–
Gianluca Varenni, Windows DDK MVP
CACE Technologies
http://www.cacetech.com
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, December 05, 2007 11:43 AM
Subject: RE:[ntdev] Accessing OS’s highest Physical memory
> Hi,
>
> I’m trying to reserve a portion of physical memory for DMA transfers.
> I’m doing this through my application. In order to do this I need the
> OS’s highest Physical address. So far I haven’t found a way to retrieve
> this and decipher the .Translated value.
>
> Thanks.
>
> —
> 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
xxxxx@yahoo.com wrote:
I’m trying to reserve a portion of physical memory for DMA transfers. I’m doing this through my application. In order to do this I need the OS’s highest Physical address. So far I haven’t found a way to retrieve this and decipher the .Translated value.
Chris and I have been discussing this offline. He’s using the Jungo
tools, which move most of the driver into user mode. I think I have now
realigned him on the path towards enlightenment.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Well that seems rather problematic for many reasons, but your answer does
not answer the question “why do you need the highest physical address”?
Applications should not be reserving physical memory at all. The OS reserves
physical memory, and provides kernel interfaces for doing so. “reserved
physical memory for dma operations” would be one definition of what the
Windows OS refers to as a “Common Buffer”. Perhaps that is what you actually
need, you should acquire it in your driver when your device is loaded, and
not attempt to have an application perform this sort of task.
On Dec 5, 2007 2:43 PM, wrote:
> Hi,
>
> I’m trying to reserve a portion of physical memory for DMA transfers.
> I’m doing this through my application. In order to do this I need the OS’s
> highest Physical address. So far I haven’t found a way to retrieve this and
> decipher the .Translated value.
>
> Thanks.
>
> —
> 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
>
–
Mark Roddy
Thanks, guys! I appreciate all the responses. Thanks to Tim and everyone else I have a much clearer picture of what needs to be done.
Mark Roddy wrote:
Well that seems rather problematic for many reasons, but your answer
does not answer the question “why do you need the highest physical
address”?Applications should not be reserving physical memory at all. The OS
reserves physical memory, and provides kernel interfaces for doing so.
“reserved physical memory for dma operations” would be one definition
of what the Windows OS refers to as a “Common Buffer”. Perhaps that is
what you actually need, you should acquire it in your driver when your
device is loaded, and not attempt to have an application perform this
sort of task.
Yes, that is exactly what he needs. The Jungo web site actually
recommends using /burnmemory to carve out a chunk at the end of physical
memory, then using the .Translated registry key to locate that memory.
That’s what prompted his question. Again, Chris and I have been
exploring better methods of achieving his goal. I think this thread can
be allowed to die.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
>
> Yes, that is exactly what he needs. The Jungo web site actually
> recommends using /burnmemory to carve out a chunk at the end of physical
> memory, then using the .Translated registry key to locate that memory.
> That’s what prompted his question. Again, Chris and I have been
> exploring better methods of achieving his goal. I think this thread can
> be allowed to die.
>
Of course the /burnmemory trick has problem, at least prior to Vista
burnmemory did not take memory from the end of physical memory. I never
went and explored this on Vista so I cannot say. Prior to Vista you needed
to use /MAXMEM.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Not to mention the fact that it only works for one driver. God forbid
you load two of these.
“Don Burn” wrote in message news:xxxxx@ntdev…
>
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>>
>> Yes, that is exactly what he needs. The Jungo web site actually
>> recommends using /burnmemory to carve out a chunk at the end of
>> physical
>> memory, then using the .Translated registry key to locate that
>> memory.
>> That’s what prompted his question. Again, Chris and I have been
>> exploring better methods of achieving his goal. I think this
>> thread can
>> be allowed to die.
>>
> Of course the /burnmemory trick has problem, at least prior to Vista
> burnmemory did not take memory from the end of physical memory. I
> never went and explored this on Vista so I cannot say. Prior to
> Vista you needed to use /MAXMEM.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
My hardware people have this need for their diagnostics program. I have added a driver API where the diag can ask for a contiguous buffer, which they use to do dma “by hand”, that is, accessing the chip registers directly. My driver allocates a sizable slab of contiguous kernel memory at start time (its size is configurable through a registry entry), so that when I get this diag request I suballocate a buffer, get an mdl for it, and map it in user visibility so that the diag program can access it.
I have a similar piece of functionality that allows the diag program to ask for a mapping for the chip’s BAR registers’ address ranges.
This is rather dirty functionality, and we do not want our users to have access to it, so, we surround it with some safety valves to make sure that only the diag program can access it. We have been mulling, on and off, about moving all that dirty functionality to a diag filter driver, which wouldn’t be distributed to our users.
Note that the MmAllocateContiguousMemory requires the highest acceptable physical address, which doesn’t need to be the highest machine address. You can restrict it to a low value, for example, if you’re doing a stress test, but my experience is that I can set it to all Fs without much of a problem. However, there are Microsoft people in this list who can shed more light on this issue!
Hope this helps,
Alberto.
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Wednesday, December 05, 2007 3:09 PM
Subject: Re: [ntdev] Accessing OS’s highest Physical memory
Well that seems rather problematic for many reasons, but your answer does not answer the question “why do you need the highest physical address”?
Applications should not be reserving physical memory at all. The OS reserves physical memory, and provides kernel interfaces for doing so. “reserved physical memory for dma operations” would be one definition of what the Windows OS refers to as a “Common Buffer”. Perhaps that is what you actually need, you should acquire it in your driver when your device is loaded, and not attempt to have an application perform this sort of task.
On Dec 5, 2007 2:43 PM, wrote:
Hi,
I’m trying to reserve a portion of physical memory for DMA transfers. I’m doing this through my application. In order to do this I need the OS’s highest Physical address. So far I haven’t found a way to retrieve this and decipher the .Translated value.
Thanks.
—
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
–
Mark Roddy — 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
Alberto,
Hope this helps,
I seriously doubt it - the OP believes that context switch may occur in the same CPU that has queued a DPC before DPC routine gets executed ( I already don’t mention the fact that his objective in itself is just ridiculous - after all, the period that elapses in between his app does IO request and the one its call to DeviceIOControl() returns control depends not on how fast interrupt in itself gets processed but on when his thread is given its time slice). Therefore, I am afraid that, first of all, he just needs to learn the basics of kernel mechanics - otherwise, no matter how good your advice is, he will be just unable to make any use of it anyway…
Anton Bassov
Guys,
It is just incredible - for this or that reason, a post that I made on thread “KeSetEvent/DPC” somehow appeared on this thread. Sorry, but this is not my fault…
Anton Bassov