I am told that I can find the physical address corresponding to a virtual address using /proc/[pid]/pagemap.
I read that this pagemap file is an array of 64-bit entries, with bits 0-54 corresponding to the page frame number. I don't know how to make the leap from this to translating virtual to physical. Partially, I don't know how to find the entry I want in this file; nobody seems to specify how they are indexed.
Also, I don't know if the PFN is virtual or physical. And I don't know what to do with the PFN, regardless. How can I proceed?
Thanks
Divide the VA by the page size (4096 normally), use that as an offset into /proc/self/pagemap. Then take that number (the page), multiply by the pagesize (4096), and offset that by your VA%4094.
Larry
Related
I am aware that there is a little information regarding the pagemap file here. But nobody seems to indicate how to reference entries in the file. Is it offset by virtual address? Can I take a virtual address VA and simply lseek to offset VA? Or is it by page? If so, how do I retrieve the page number, as maps simply lists them in order. I am trying to translate between virtual and physical addresses, and lseek'ing with the virtual address as the offset always returns the same number, no matter where I seek to.
Thanks
#leeduhem: Yes I have. Here's the relevant part:
3. Open /proc/pid/pagemap and seek to the pages you would like to examine.
4. Read a u64 for each page from pagemap.
That doesn't help me. It wants me to seek to the page, but how do I know where the entry for the page is?
There is a tool that will help you to get information you need from the pagemap file.
http://fivelinesofcode.blogspot.com/2014/03/how-to-translate-virtual-to-physical.html
You divide the virtual address by the pagesize (normally 0x1000 or 4096) and use that to index in /proc/self/pagemap. After the division, that's known as the PFN, or page frame number.
Larry
I want to write data to an arbitrary physical memory address to test the error detection and correction feature of my system. One code segment in an existing kernel module is written like this:
u32 addr;
struct page *page;
void *mem;
pci_read_config_dword(priv->mc, I5100_MEMEINJADDRMAT, &addr);
/* Inject error by writing to address */
page = pfn_to_page(addr >> PAGE_SHIFT);
mem = kmap(page) + (addr & (~PAGE_MASK));
*((volatile u32*) (mem)) = 0x01010101;
kunmap(page);
I5100_MEMEINJADDRMAT is the register address of a register in i5100 memory controller. Basically, the memory address is retrieved in that register. I don't understand the remaining code, starting from retrieving a page then perform bitwise operations.
As far as I understand, pfn_to_page is used to get a page that includes a particular physical address by passing in a page frame number as argument. The addr >> PAGE_SHIFT part is to translate from a given address to its corresponding page frame number. But, I don't understand how to use PAGE_SHIFT correctly? What should be the correct data type to use with PAGE_SHIFT?
kmap() returns the appropriate virtual page address then add the offset to get the correct pointer to a virtual memory address. What does (addr & (~PAGE_MASK)) actually do?
My task is to write error injection to a physical address? But the above code seems to write to a virtual address. Is there any other way?
This:
(addr & (~PAGE_MASK))
will clear the bits in addr that are set in PAGE_MASK. Assuming a page size of 4 KB, the PAGE_MASK will likely have its 12 least significant bits set, since 212 = 4096.
So, PAGE_MASK is 0x00000fff. Then, the bit-wise inverse ~PAGE_MASK is simply 0xfffff000, so when addr is bitwise-and:ed with this, the lowest 12 bits of addr are cleared.
/* PAGE_SHIFT determines the page size */
#define PAGE_SHIFT 12
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE-1))
I found these definition in linux-source-3.2.0.
but I get PAGE_MASK is 0xfffff000
so I think this operator is clearing the highest 20bit, or try to get the value of lower 12 bit.
page = pfn_to_page(addr >> PAGE_SHIFT);
It gets the page address using page frame number (page frame number (pfn) is obtained shifting to right the address). Because least significant bits represent offset in the page (12 bits for x86). Page frame number is equal to 20 most significant bits of the physical address for x86.
You can apply shifting on pointer or integer data types. It depends on the situation.
(addr & (~PAGE_MASK)) gets inner offset of the frame. To access correct byte you should add offset to related page.
Virtual address represents physical address. As far as I know, there is no way other than using virtual address. Also, I should say this is kernel virtual space, it is different from userspace virtual addresses.Do not mix userspace with kernel space.
I've looked at a few different articles related to this already but none of them explain the solution in a way that I can understand and replicate. I need to know how to translate a physical address to a virtual address in memory based on the following:
A simple virtual memory system has 32KB physical memory with 16-bit virtual address, of which 12 bits are used as offset. The following is the current content of the page table of one of the processes:
So basically I think the page size of this virtual memory system is 1024KB. I need a process to find the corresponding PA of VA B2A0. If you can give me the process I can go from there, you don't have to give me the final solution :)
Thanks in advance guys. Also, if you know of an article that does this already and I've just missed it, feel free to just link me to that.
Cheers.
32 KB is 2^15.
so there are 15 bits for every physical address, lower 12 of them are used as offset, higher 3 as a number of pageframe.
What virtual page does 0xb2a0 resides in? To determine this, we need to take bits of the address, higher than 2^12. The size of a page is 2^12, that is 4096 or 0x1000, so it is a virtual page number 0xb = 11 (floor of 0xb2a0 / 0x1000). Offset inside the page is 0xb2a0 modulo 0x1000, it's 0x2a0.
Then use the table to translate the virtual page number 11 to a physical pageframe. The virtual page is present (1), and it corresponds to the physical frame number with higher bits 111, that is 111 + twelve 0 in binary, => 0x7000 - it is the address of the start of the physical frame.
Our physical address resides at offset 0x2a0, so, the sought physical address is 0x7000 + 0x2a0 = 0x72a0.
Please, follow this flow and make it clear for you. If you have questions, read the Wikipedia first and if something is still not clear, ask :)
I was trying to do my examination review and study, and I couldn't find a solid answer to this same question. I consolidated what I have learnt, and I hope that whatever I summed up here will help those like me. :)
I find the explanation in the answer above a little hard to understand for my little brain.
I think this link below gives a better overview than Wikipedia's explanation:
http://williams.comp.ncat.edu/addrtrans.htm
This youtube video also offers an excellent guide in explaining the process of virtual address translation:
https://www.youtube.com/watch?v=6neHHkI0Z0o
Back to the question ->>>
The first question is - what is the 'page size' of this virtual memory system?
based on the definition here - https://en.wikipedia.org/wiki/Page_(computer_memory)
I was initially confused between 'pages' and 'page size' but I kinda figured it out now. Pages determines the number of pages available (like in a book), and page size is like (A4,A5,A6 pages in the book!).
As such, since the virtual memory and physical memory offset is the same and is mapped accordingly, we can determine the page size via the offset size. If the offset size is given as 12-bit, then 2^12 = 4,096 Byte a.k.a 4-KB.
Side question for curious minds, how many virtual memory pages are there?
- 16-bit of virtual address space minus 12-bit of offset = 4-bit
- which equals to 2^4 = 16-pages available (thus the table we see!)
Another side question for other curious minds, how many PHYSICAL memory pages are there?
- 32KB of physical Memory = 32 x 1024bytes = 32,768 bytes
- Log(32768) / Log(2) = 15-bits which also means 2^15 for total physical MEMORY
- minus the offset of 12-bit that we already know...
- 15-bit (total physical memory) minus 12-bit (offset) = 3-bit for physical address space
Going to the next question, what is the corresponding physical address of virtual address 0xb2a0 (that is currently set in hex notation)?
#Dmytro Sirenko answer above explains it quite well, I will help to rephrase it here.
We need to remember that our virtual address is - 16-bit, and that address space now contain is value = b2a0 (ignoring the 0x).
My short-cut (please correct me if am wrong), is that since the ratio of the address : offset (page size) is 4:12 = 1:3...
b | 2 a 0
^
page number | offset
When converting hex value b to decimal = 11.
I look into the table, and I found Page Frame = 111 in the table entry number 11.
111 is noted in binary and it correlates to the physical memory frame.
Remember, we were looking at 15-bit of Physical Memory Address space, as such, we can determine that:
1 1 1 | 0 0 0 0 0 0 0 0 0 0 0 0
Address | offset
As Offset are mapped directly from virtual memory to physical memory, we bring the value of (2a0) right into the physical memory. Unfortunately, we can't represent it right away in here because it's in hexadecimal format while my above address space is set in binary.
Considering that I am going to be tested in an examination and I won't be allowed to bring in a calculator... I will do a reverse and answer in Hexadecimal instead. :)
When we convert 111 into decimal (I go by 001 = 1, 010 = 2, 100 = 4, 101 = 5, 110 = 6, 111 = 7).
Now I need to convert from decimal to Hex! = 7 (dec) = 7
As such, the corresponding Physical Memory location of this virtual memory address is.... (loud drums and curtain open....)
7 2 a 0
which is notated in this manner 0x72a0.
From LDD3/ Ch. 15/ sections "Using remap_pfn_range" and "A Simple Implementation", pfn has been equated to the vm_pgoff field. I am confused by this. How can that be so?
Note that vm_pgoff is described as:
The offset of the area in the file, in pages. When a file or device is
mapped, this is the file position of the first page mapped in this
area.
Thus if the first page mapped corresponds to the first page of the file as well (which, I think would be quite common), vm_pgoff would be 0. correct? If so, this doesn't seem to be the correct value for the pfn parameter of remap_pfn_range( ). What am I missing here? What is the correct value? For ease of reference, I am reproducing the relevant code from LDD3 below (Page no. 426)
static int simple_remap_mmap(struct file *filp, struct vm_area_struct *vma)
{
if (remap_pfn_range(vma, vma->vm_start, vm->vm_pgoff,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
...
}
The specific example you've provided is implementing a character device file that allows one to map physical memory, very similar to /dev/mem. By specifying the offset of the file you specify the physical memory address. Hence the calculation that takes the offset and divide in the page size to find the PFN.
For a "real" device driver, you would normally have the physical address of the device memory mapped registers or RAM hard coded from the device specification, and use that to derive the PFN (by dividing by the page size).
What is the difference between a relative virtual address and an offset from the base of a file??
The RVA is the relative-virtual address, that is, the distance from the preferred base address. The preferred base address is stated in the PE header, and is the (preferred) virtual address of the start of the image in memory for when the executable be loaded in memory.
And the file offset is the number of bytes you have to read from the beginning of the PE file to arrive somewhere in the file. So, if you have a section, you will find both things in the section header: the RVA of the section and its offset in the file; you will also find two sizes, one for how much virtual memory the section will get once loaded and one that merely indicates the size of the section data in the PE file.
Many references inside a PE are given as RVAs. In such cases, you need to check in all the section headers (or have some sort of map) to get the offset in the PE file of the reference.