Virtual Memory and Address Translation: Mapping Virtual Addresses to Physical Addresses
Virtual memory is an operating-system and hardware abstraction that lets each process use a large, private, contiguous virtual address space, even though physical RAM is limited and shared. The key mechanism is paging: memory is divided into fixed-size blocks called pages, and each process has a set of virtual pages mapped to physical frames.
When the CPU generates a virtual address and needs to access memory, the hardware (MMU) translates it into a physical address using:
- the page table, and
- a small hardware cache called the TLB.
Virtual Memory: 7 Address Translation Example Walkthrough
Diagram: end-to-end virtual→physical translation
The diagram below shows the major steps: split the virtual address into VPN and offset, consult the TLB, otherwise walk the page table, then reconstruct the physical address by combining physical frame with the unchanged page offset.
This “offset stays the same; page number is translated” pattern is explicitly described in virtual-memory translation explanations: the MMU dissects the virtual address into a virtual page number and page offset; the offset bits are passed through unchanged, while the virtual page number is translated using TLB/page-table state.
Footnotes
-
How is Virtual Memory Translated to Physical Memory? - VMware Cloud Foundation (VCF) Blog - Explains splitting VA into VPN and offset; offset passthrough; TLB lookup logic. ↩
Virtual address structure (VPN + offset)
For paging systems with fixed page size, the virtual address can be conceptually decomposed as:
- Offset selects a byte within the page.
- VPN identifies the virtual page.
- The translation replaces the virtual page’s identity with a physical frame identity.
Common references describe that the offset bits are not translated and are carried through directly into the final physical address.
Footnotes
-
How is Virtual Memory Translated to Physical Memory? - VMware Cloud Foundation (VCF) Blog - Explains splitting VA into VPN and offset; offset passthrough; TLB lookup logic. ↩
How VPN is mapped to PFN (page tables + TLB)
-
TLB fast path (TLB hit):
The MMU checks whether the translation for the given VPN is already cached in the TLB. If present, the TLB provides the physical frame number (PFN) quickly; this avoids consulting the page table in main memory.2 -
Page table slow path (TLB miss):
If the translation is not in the TLB, the MMU performs a page walk through the page table to locate the page table entry (PTE) for that VPN, which contains (at least) the PFN and protection/validity metadata. After the PFN is found, the translation is stored into the TLB for future accesses.
The TLB is specifically described as an address-translation cache that stores recent virtual→physical translations, and that on a miss it falls back to page table lookup (“page walk”).
Footnotes
-
Translation lookaside buffer - Wikipedia - Defines TLB as an address-translation cache; TLB hit/miss behavior and page walk fallback. ↩ ↩2
-
Paging: Faster Translations (TLBs) (OSTEP VM-TLBs) - Describes TLB as a hardware cache of popular virtual-to-physical translations and why it makes virtual memory possible. ↩
-
Page table - Wikipedia - Describes page table role and translation flow including TLB search then page walk on miss. ↩
Step-by-step virtual address translation (VPN → PFN, then compose PA)
- 1Step 1
Extract the offset (low bits) and the VPN (remaining bits).
- 2Step 2
Query the TLB for a cached translation. If found (TLB hit), obtain the PFN.
- 3Step 3
Use the page table to find the PTE corresponding to the VPN; the entry yields the PFN (and may also include validity/protection bits).
- 4Step 4
Form the physical address by concatenating the PFN’s physical frame base with the unchanged offset.
- 5Step 5
Use the resulting physical address to access memory hardware (and, if there was a miss, the translation is typically recorded in the TLB for reuse).
Why the TLB makes virtual memory fast
A page-table walk may require multiple memory accesses, so the TLB exists to avoid that cost for repeated translations—making the common “fast path” (TLB hit) practical at CPU speeds.2
Footnotes
-
Translation lookaside buffer - Wikipedia - Defines TLB as an address-translation cache; TLB hit/miss behavior and page walk fallback. ↩
-
Paging: Faster Translations (TLBs) (OSTEP VM-TLBs) - Describes TLB as a hardware cache of popular virtual-to-physical translations and why it makes virtual memory possible. ↩
TLB hit vs. page table state (and process context switches)
During a context switch, the CPU must ensure translations correspond to the currently running process. TLB entries are therefore managed (e.g., invalidated or tagged) so an old process’s VPN→PFN mapping is not mistakenly reused.
Footnotes
-
Paging: Faster Translations (TLBs) (OSTEP VM-TLBs) - Discusses TLB valid bits and context-switch considerations. ↩
Where virtual memory translation occurs in the MMU pipeline
Virtual address produced
1. CPU generates VAThe CPU forms a virtual address for a load/store."
Split into Offset + VPN
2. Offset extractionMMU extracts the offset and VPN."
Translation cache check
3. TLB lookupMMU probes the TLB for VPN."
Consult page tables
4. Page walk (if needed)On a miss, hardware/OS performs a page-table walk to get the PFN."
Physical address assembled
5. Compose PAMMU combines PFN with unchanged offset to produce PA."
Data/instruction fetched
6. Memory accessActual RAM access occurs using the physical address."
Virtual address translation paths: fast TLB hit vs. slower page-table walk
Relative latency concept: TLB hit avoids consulting memory-resident page tables; miss requires a page walk.
Key nuances and edge cases
Knowledge Check
In typical paging-based virtual memory, what part of the virtual address is translated?