Example: Virtual Address to Physical Address#

The CPU uses page tables to translate a virtual address into a physical address.

Kernel code
    |
    | Access virtual address
    v
0x10000004470
    |
    | CPU MMU consults page tables
    v
0x00604470
    |
    v
Physical RAM

2.1 Layout of a 4 KiB Page#

2.2 Page Offset Examples#

The offset identifies a byte’s position relative to the beginning of a page.

2.3 How the CPU Uses the Page Offset#

When translating a virtual address, the CPU translates the virtual page to a physical page and preserves the offset within that page.

For example, suppose virtual page 0x4000 maps to physical page 0x9000.

The calculation is:

Virtual address  = 0x4000 + 0x234 = 0x4234
Physical address = 0x9000 + 0x234 = 0x9234

The page-table entry determines the physical page base. The CPU preserves the 12-bit offset when translating a standard 4 KiB page.

Key takeaway: A page is a 4096-byte block, and the 12-bit page offset selects a byte within that block. The page tables determine which physical page corresponds to a virtual page.

• The CPU can translate the page’s starting address, then preserve the offset within that page.

A page table maps virtual pages to physical pages.

For example, a virtual page starting at 0x4000 might map to a physical page starting at 0x9000.

The low 12 bits are the offset within a 4 KiB page, because $(4096 = 2^{12})$.

The page-table lookup translates the page number; the CPU keeps the page offset unchanged.

Four-Level x86-64 Page-Table Hierarchy#

CR3
 |
 v
Level 4: PML4
 |
 v
Level 3: PDPT
 |             \
 v              v
Level 2: PD     1 GiB page
 |              (large-page mapping)
 +----------+
 |
 v
Level 1: PT
 |             \
 v              v
4 KiB page     2 MiB page
               (large-page mapping)

Level 4 — PML4#

Selects a Level 3 table

Level 3 — PDPT#

Selects a Level 2 table or a 1 GiB page

Level 2 — Page Directory#

Selects a Level 1 table or a 2 MiB page

Level 1 — Page Table#

Selects a 4 KiB physical page

Physical RAM page

The names can be confusing, so start with the abbreviations:

The correct spelling is PML4, not PLM4.

4. How a Virtual Address Is Divided#

For conventional x86-64 four-level paging with 48-bit virtual addresses, the CPU divides the address into five fields.

  47          39 38          30 29          21 20          12 11           0
 +--------------+--------------+--------------+--------------+--------------+
 | PML4 index   | PDPT index   | PD index     | PT index     | Page offset  |
 |    9 bits    |    9 bits    |    9 bits    |    9 bits    |    12 bits   |
 +--------------+--------------+--------------+--------------+--------------+

5. Level 4 — PML4#

The PML4 is the first table the CPU uses during a four-level page-table walk.

Its physical address is stored in CR3. The CPU uses the highest nine relevant bits of the virtual address to select one of its 512 entries.

Each PML4 entry normally points to a PDPT.

For example:

CR3 = physical address 0x1000
             |
             v
      PML4 at 0x1000
      ┌──────────────┐
      │ Entry 0      │
      │ Entry 1      │
      │ ...          │
      │ Entry 4      │ ─────> PDPT at 0x2000
      │ ...          │
      │ Entry 511    │
      └──────────────┘

These addresses are illustrative; the page-table memory must actually be allocated and initialized before the CPU uses it.

The PML4 entry does not usually contain the final physical address of the data. It contains the physical address of the next-level table, along with permission and status flags.

6. Level 3 — PDPT#

PDPT stands for Page Directory Pointer Table.

The CPU uses the next nine bits of the virtual address to select one of its entries.

That entry can do one of two things:

1. Point to a page directory at Level 2.
2. Map a 1 GiB page directly, if large-page support and the relevant entry flags are enabled.

PDPT at 0x2000
┌────────────────────────┐
│ Entry 0 ──> Page Dir   │
│ Entry 1 ──> Page Dir   │
│ Entry 2 ──> 1 GiB page │  (if configured)
│ ...                    │
└────────────────────────┘

A 1 GiB page is useful when the kernel wants to map a large, contiguous region without constructing thousands of smaller page mappings.

7. Level 2 — Page Directory#

The page directory is the next level down.

The CPU uses another nine address bits to select an entry. The entry can either:

• Point to a Level 1 page table.
• Map a 2 MiB page directly, when the entry’s huge-page flag is set.

Page Directory at 0x3000
┌──────────────────────────┐
│ Entry 0 ──> Page Table   │
│ Entry 1 ──> Page Table   │
│ Entry 2 ──> 2 MiB page   │  (huge page)
│ ...                      │
└──────────────────────────┘

A 2 MiB page contains 512 standard 4 KiB pages:

$512 \times 4096 = 2{,}097{,}152\text{ bytes}$

This can reduce the number of page-table entries and improve translation efficiency for large mappings.

8. Level 1 — Page Table#

The final level maps individual 4 KiB pages.

The CPU uses the final nine index bits to select an entry. This entry identifies the physical page frame and includes flags describing access permissions.

Page Table at 0x4000
┌──────────────────────────┐
│ Entry 0 ──> RAM page     │
│ Entry 1 ──> RAM page     │
│ Entry 2 ──> RAM page     │
│ ...                      │
│ Entry 511 ──> RAM page   │
└──────────────────────────┘

At this level, the CPU has found the physical page frame. It combines that page’s physical base address with the original 12-bit offset to obtain the final physical address.

If an entry is not present, the CPU cannot complete the translation normally and raises a page-fault exception.

10. Calculate the indexes in Rust#

This small Rust program demonstrates how to extract the four indexes and the page offset. It does not access hardware or create page tables.

fn main() {
    let virtual_address: u64 = 0x0000_0000_0040_1234;

    let pml4_index = (virtual_address >> 39) & 0x1FF;
    let pdpt_index = (virtual_address >> 30) & 0x1FF;
    let pd_index   = (virtual_address >> 21) & 0x1FF;
    let pt_index   = (virtual_address >> 12) & 0x1FF;
    let offset     = virtual_address & 0xFFF;

    println!("Virtual address: {virtual_address:#018x}");
    println!("PML4 index:      {pml4_index:#x}");
    println!("PDPT index:      {pdpt_index:#x}");
    println!("PD index:        {pd_index:#x}");
    println!("PT index:        {pt_index:#x}");
    println!("Page offset:     {offset:#x}");
}

Run it with:

rustc address.rs -o address
./address

Expected output:

Virtual address: 0x0000000000401234
PML4 index:      0x0
PDPT index:      0x0
PD index:        0x2
PT index:        0x12
Page offset:     0x234

The mask 0x1FF selects nine bits. The mask 0xFFF selects the last twelve bits.

11. What does a page-table entry look like in Rust?#

At a low level, an x86-64 page-table entry is a 64-bit value. Some bits encode the physical address; other bits encode flags.

For a simplified example:

const PRESENT: u64 = 1 << 0;
const WRITABLE: u64 = 1 << 1;
const HUGE_PAGE: u64 = 1 << 7;

fn main() {
    // Illustrative physical address of a page-aligned table.
    let next_table_phys: u64 = 0x2000;

    // Mark this entry present and writable.
    let entry = next_table_phys | PRESENT | WRITABLE;

    println!("Entry: {entry:#018x}");
    println!("Present: {}", entry & PRESENT != 0);
    println!("Writable: {}", entry & WRITABLE != 0);

    // HUGE_PAGE has a different meaning depending on the level.
    println!("Huge-page flag bit: {HUGE_PAGE:#x}");
}

Output:

Entry: 0x0000000000002003
Present: true
Writable: true
Huge-page flag bit: 0x80

Here, 0x2000 is the next table’s physical address, while the low bits mark the entry as present and writable.

This is only a teaching example. A real kernel must validate physical-address bits, alignment, flags, memory allocation, and CPU paging requirements. The huge-page flag also has level-dependent semantics; setting the bit indiscriminately is not a valid mapping strategy.

12. How large pages change the walk#

Not every translation needs all four levels.

For example, when a Level 2 entry maps a 2 MiB page, the CPU does not need a Level 1 table for that region. The physical base address comes from that directory entry, and the low 21 bits of the virtual address select a byte within the 2 MiB page.

13. What your Rust kernel needs to do#

When implementing paging in your own x86-64 kernel, the broad process is:

1. Reserve suitably aligned physical memory for the page tables.
2. Initialize the entries to represent the mappings you need.
3. Ensure the page tables themselves are accessible while setting them up.
4. Load the physical address of the top-level table into CR3 if your kernel is responsible for that step.
5. Enable or maintain the appropriate paging and CPU mode settings.
6. Ensure the currently executing code, stack, and required data remain mapped when switching address spaces or enabling paging.

• Your earlier QEMU boot log showed the bootloader reporting a new page table at physical address 0x101000, then entering your kernel at a virtual address. That indicates the bootloader was already performing part of the paging setup. You should inspect the boot protocol and its handoff information before building a second set of page tables.

• The core idea: Level 4 selects a Level 3 table, Level 3 selects a Level 2 table, Level 2 selects a Level 1 table, and Level 1 selects a 4 KiB physical page. Large-page entries can end that walk earlier.