I am reporting this from Newbie thread. I didnt get much help there.

Hi All,

I have been trying to run through an exercise to open a filepointer for /dev/mem in user space and navigate over all of the mem_map entries (struct page entries). In order to get started on this, I wrote a kernel module to display start of memmap logical address and also its physical address. I used the functions pfn_to_page(0) to get the logical address and __pa(pfn_to_page(0)) to get its corresponding physical address.
The output of this kernel module is something like this
MemMapLogicalAddress=ffffea0000000000
MemMapPhysicalAddress=0000620000000000
NumPhysicalPage=524288
PageSize=4096
PageOffset=ffff880000000000

When I try to use mmap to map to the physical address above it works fine but when I try to read values from that map_base, my process gets killed and when I look into /var/log/messages there is a message that says bad PGD.

My question is why is physical address (0000620000000000) beyond 4gb, I have only 2GB memory but its a 64 bit machine. Am I missing something here?

LOL. Was waiting for this.

Bus addresses on most real-world x86_64 systems (Core2, Xeon, AMD *) are no more than 40-bits (either 40 or 36.) So in practice, it doesn't matter.

The address you mention would throw away the first 24 bits (or 6 hex chars.) So the address is really 0x0000000000.

I suspect the first 6 chars are being used by Linux to provide some additional flags/info, or to annote that the bus address is for main memory.

I suspect also that there's a common way to mask that address, to get all zeros; something (in spirit) like:

1 members found this post helpful.

Interesting guess. I don't know the answer either, but my guess is that your guess is incorrect.

If you don't know exactly what the macros __pa and pfn_to_page do then you don't know the answer to the original post.

Part of the kernel virtual address space in Linux is a contiguous mapping of physical memory. If you use the __pa macro on a virtual address in that range you get the corresponding physical address. But are the page tables in that range or what does __pa do if you use it in some other range? I don't know.

Since the page tables should be sparse, they shouldn't be in a contiguous physical mapping. In order to be efficient for the common use, the __pa macro ought to just subtract a fixed offset. Combining those should mean using __pa on an address within a page table ought to give you garbage just like what it is giving. So all that is my guess.

Because that number is garbage and is not a physical address.

With less than 4GB of ram, you might have some ram with physical addresses greater than 4GB. But that is very unlikely with only 2GB of ram (even with 3GB it is fairly unlikely). Also it still could not be a wildly large physical address. Larger than 4GB is possible, but 0x620000000000 is not.

0 members found this post helpful.