Linux page table - linux-kernel

In Linux, there are functions such as pgd_offset, pmd_offset and pte_offset which are used to index to the pgd, pmd and pte. Who calls these functions? Does the MMU use these functions to walk the page tables?
My understanding is that the linux kernel creates a page table for each process and passes the base address of the page table to the page table base register so the MMU can access it. How does the MMU read the page table afterwards? Who uses those pgd_offset, etc functions if the MMU is the one reading the page tables?

How does the MMU read the page table afterwards?
The MMU is using hardware an accelerated method in order to read memory. The actual lookup is architecture-specific: just like the instruction parsing process.
Who uses those pgd_offset, etc functions if the MMU is the one reading the page tables?
Sometimes, kernel code want to lookup a struct page by a virtual address. It must use these functions in order to do this (AFAIK, there is no API for MMU address lookup. Therefore, it must be implemented in the kernel too).

Related

Is a process' page table mapped to Kernel address space?

I was doing Windows system programming and wondered if I can access a process' page table on source code level.
Here is what I know about page table related to virtual memory.
Let's suppose an user just runs a process called 'A' process on Windows OS(32bit).
First of all, the OS creates and maintains 4GB virtual address space for A process.
(2GB of it is Kernel address space and the other 2GB is User address space.
Any codes in User address space cannot directly access Kernel address space.)
Then, the OS creates and maintains a page table for A process in physical memory to map virtual memory address to physical memory address.
Here is my question.
After OS creates a page table for A process, is this page table mapped to A's Kernel address space so user can indirectly access the page table from source code?
Or the page table is not mapped to any of A's virtual address spaces but just resides only in physical memory so user cannot access the page table?
To speed up manipulation of page tables, the kernel normally makes one entry in the page directory point to the page directory. This makes all page tables mapped and accessible in the address space. However, as Raymond Chen has indicated, these are not accessible from user mode. There's no good reason to allow applications to mess with page tables. There are APIs to allocate (and map) regions of address space and those should be used instead.
You mean there are page table entries in the kernel address space of 'A' process' virtual memory, and those entries are mapped to the real page table residing in physical memory. So, the process can access these page table entries only if it has kernel mode, but the process does not have it. Therefore, the process cannot access its page table after all. Is it right?
Right. Accessibility of pages is governed by the current privilege level (user vs kernel), segment access rights and page access rights. The particular combination of these employed in the system does not let code running in user mode access kernel data, including the page directory and page tables.

Will multilevel page table have any advantage if we don't have secondary storage?

In two level address translation, it's said that the first level page table (1K entries)will always be there in main memory for a process.
Out of 1K second level page tables , only those page tables will be there in memory which are currently in use.
Where will we store other second level page tables ( which are not currently in use) in the absence of any secondary storage (e.g. in embedded systems)?
If we can't swap out second level page tables from memory, is there no advantage of Two level Address Translation?
The advantage of a multi-level table for logical address translation without virtual memory is that one can have dynamic page table size (even if it is not paged out). Paging is just on possible benefit (however, systems with dedicated system address spaces can page page-tables without having nesting).

Does an entry of page table represents a page or a linear address?

I reading the book Understanding the linux kernel, and the topic about address transition very confuses me. Book says each linear address has three fields: Directory, Table, and Offset. The Directory field relates to the Directory Table, and Table field relates to Page Table.
One thing it does not point out, or I may miss, is that whether each entry in the tables relates to a page, which is a group of linear addresses, or relates to an individual linear address.
Can someone help me?
Ok, so there are (at least) two types of page tables: single-level, and multi-level.
Single-level page tables' entries map directly to virtual addresses.
Multi-level page tables' entries can map to two different places:
They may map directly to virtual memory addresses (like single-level tables).
They may map to secondary (or tertiary, etc, etc.) page tables
Here's an example of a multi-level page table:
Remember, each page table entry holds a virtual address. It is the responsibility of the operating system to translate virtual addresses to physical addresses (the benefits of which are outside of this particular topic).
Most paging systems also maintain a frame table that keeps track of used and unused frames. The frame table is traditionally a different data structure than the page table.
You can read more about paging tables here.
You can read about page tables here.

How is the virtual address of the page table is converted to its actual physical address?

If paging is enabled in OS, a page table is used to map the virtual address to the actual physical address. To be more specific, consider Linux 32 bit OS on X86, the cr3 register has the starting address of the page table directory. I guess this is a virtual address. How will the CPU maps this virtual address to the physical address of the page table directory on RAM.
Which page table will be used for this address translation?
No, cr3 has the physical address of page table, not the virtual address. If cr3 contains the virtual address of page table, you'll fall into a logic dead loop and have no way to find page table.
The paging unit translates linear addresses into physical ones.
Set of linear addresses are grouped together to form a page. These linear addresses are continuous in nature - the paging unit maps these sets of contiguous memory to corresponding set of contiguous physical addresses called page frames. Please note that the paging unit is divided into RAM page frames of fixed size. For this reason, the pagination has the following advantages:
Permissions defined for the page will be valid for a group of linear addresses forming a page
The page length is the length of the page frame
The data structure that maps these pages to page frames, called a page table. These page tables are stored in main memory and the kernel is initialized before the resolution of the module management pages.
see to the link

How Linux Operatin g System maintains Page Table?

Does page table per Process or per System ?. Is KERNEL maintain entire single shared page table for all process ?
Most OS's allocate the page table for each process and store the pointer of the table in the register and include it in the PCB

Resources