Page Fault Detection

Every time a process accesses memory, a complex dance occurs between the CPU and the Memory Management Unit (MMU). Most of the time, this dance is invisible and instantaneous—the virtual address maps to a physical frame, and execution continues. But sometimes, the requested page isn't in physical memory. At that precise instant, a page fault occurs, and the entire trajectory of the CPU changes.

Page fault detection is the foundational mechanism that enables virtual memory. Without the ability to detect when a page is absent from physical memory, the operating system would have no opportunity to bring that page in from disk. The elegance of this detection lies in its hardware-software partnership: the hardware detects the condition in nanoseconds, and the software (the OS) handles the complex recovery.

Understanding page fault detection isn't merely academic—it's essential for diagnosing performance issues, designing efficient memory management policies, and understanding why certain workloads exhibit particular behaviors. This page provides an exhaustive exploration of how page faults are detected, from the bit-level mechanisms to the architectural implications.

Before we can understand page fault detection, we must understand the fundamental contract that virtual memory provides:

The Contract: A process is given a virtual address space that appears complete and contiguous. The process can reference any valid virtual address, and the system guarantees that:

1. If the page is in memory: The access completes with the expected semantics (read returns data, write modifies data, execute runs code).
2. If the page is not in memory: The access appears to complete correctly—the page is transparently brought in from secondary storage.

This contract creates an abstraction where the process doesn't know (or care) whether its pages are currently resident in physical memory. But to fulfill this contract, the system must be able to detect when a page is absent.

The Problem: Modern CPUs execute instructions at rates exceeding 3 billion per second. Each instruction may access memory multiple times (fetch the instruction, fetch operands, store results). Detecting absent pages must happen without adding significant overhead to the memory access path—ideally, it must be free for present pages and only incur cost when a page is actually absent.

The primary mechanism for page fault detection is the valid-invalid bit (or present bit) in each page table entry (PTE). This single bit encodes whether the corresponding page is currently resident in physical memory.

How it works:

1. When a page is loaded into a physical frame, the OS sets the valid bit to 1 and records the frame number in the PTE.
2. When a page is swapped out or has never been loaded, the OS sets the valid bit to 0.
3. During address translation, the MMU checks this bit.
4. If the bit is 0, the MMU generates a page fault exception before the memory access completes.

A critical distinction: The valid-invalid bit has two different meanings depending on context:

• Semantic validity: Does this virtual address represent a legitimate part of the process's address space?
• Residency validity: Is this page currently in physical memory?

Different systems handle these two concepts differently. Some use a single bit for both meanings; others use separate mechanisms.

Page fault detection doesn't happen at an arbitrary time—it occurs at a precisely defined point in the instruction execution pipeline. Understanding this timing is crucial for understanding why page faults can be handled and instructions restarted.

The Address Translation Pipeline:

CPU generates    TLB        Page Table    Valid Bit    Physical    Memory
Virtual Address → Lookup  →  Walk (if miss) → Check   → Address  → Access
                    ↓           ↓              ↓
                  TLB Hit:   ~100-400       Fault or
                   ~1 cycle   cycles        Continue

Critical timing property: The valid bit check occurs before any memory access is performed. If the page is not present:

1. The faulting memory access has not occurred.
2. No data has been read from or written to an invalid location.
3. No registers have been modified by the faulting instruction (for simple instructions).
4. The CPU state can be captured and later restored.

This property—called precise exceptions—is what makes page fault handling possible. Modern CPUs invest significant transistor budget to ensure that exceptions are precise, meaning the processor state when the exception is taken exactly matches what it would be if execution had stopped just before the faulting instruction.

The TLB Complication:

When a translation is cached in the TLB (Translation Lookaside Buffer), the valid bit check happens implicitly. Pages with valid = 0 are never cached in the TLB. A TLB entry only exists for pages that are present in physical memory. Therefore:

• TLB hit: Page is guaranteed to be present (no fault)
• TLB miss: Must walk page table; fault may occur during walk

This design ensures that the common path (TLB hit) involves no additional checking—the presence of a TLB entry is itself proof of page validity.

The Memory Management Unit (MMU) is the hardware component responsible for address translation and, consequently, page fault detection. Modern MMUs are sophisticated pieces of circuitry that handle millions of translations per second.

MMU Components Relevant to Fault Detection:

1. TLB (Translation Lookaside Buffer): A small, fast cache of recent translations. Only valid pages have TLB entries.

2. Page Table Walker: Hardware that traverses the page table hierarchy on TLB misses. Checks each level's valid bit.

3. Permission Checker: Compares the access type (read/write/execute) against the page's permission bits.

4. Exception Generation Logic: When the valid bit is 0 or permissions are violated, this circuitry generates an exception.

The Exception Generation Process:

When the MMU detects a page fault:

1. The current instruction is aborted (if it hasn't completed).
2. The faulting virtual address is saved to a special register (e.g., CR2 on x86).
3. The type of fault is encoded and saved.
4. The CPU transitions to kernel mode.
5. Control is transferred to the page fault handler at a predefined address.

Architecture-Specific Details:

x86/x86-64: The page fault is exception vector 14 (0x0E). The faulting address is stored in CR2. An error code pushed on the stack indicates whether the fault was read/write, user/supervisor, and whether the page was present (present bit for validating if it was a permission issue vs. a true 'page not present' fault).

ARM (AArch64): Page faults generate a Synchronous Abort. The Fault Address Register (FAR) holds the faulting address. The Exception Syndrome Register (ESR) encodes the fault type.

RISC-V: Page faults are classified as load page fault, store/AMO page fault, or instruction page fault. The stval CSR holds the faulting address.

Despite architectural differences, the core detection mechanism remains the same: the MMU checks the valid bit and raises an exception if the page is absent.

While we've focused on the classic case—accessing a page that isn't in memory—the valid-invalid bit mechanism actually detects several different conditions. The OS must distinguish among these to respond appropriately.

Classification of Page Faults:

Modern systems use multi-level page tables (2-5 levels, depending on address space size and architecture). Page fault detection is more nuanced with multi-level tables because a fault can occur at any level.

Faults at Intermediate Levels:

When walking a multi-level page table, the MMU must check the valid bit of each intermediate table entry:

Level 4 (PML4)  →  Level 3 (PDPT)  →  Level 2 (PD)  →  Level 1 (PT)  →  Page
     ↓                  ↓                 ↓                ↓
  Valid?            Valid?            Valid?          Valid?

If any intermediate level entry has valid = 0, the walk terminates with a page fault. But what does this mean?

Interpretation of Intermediate Invalid Entries:

• A whole region of the address space has no physical mapping.
• The OS hasn't allocated page table pages for this region.
• This is common—most of a 64-bit address space is unmapped.

The OS Perspective:

When the OS receives a page fault, it doesn't immediately know at which level the fault occurred. The OS must:

1. Look up the faulting address in its own data structures (VMAs, memory maps).
2. Determine if the address is valid for this process.
3. If valid, determine what action to take (load from disk, zero-fill, etc.).
4. Possibly allocate intermediate page table pages before the final mapping can be created.

It's important to clearly distinguish detection from handling. This page focuses on detection—the remaining pages in this module cover handling.

Detection is a hardware operation:

• Performed by the MMU
• Takes nanoseconds
• Results in an exception being raised
• Saves minimal information (faulting address, fault type)

Handling is a software operation:

• Performed by the OS kernel
• Takes microseconds to milliseconds
• Determines what to do about the fault
• May involve complex policy decisions and I/O

The handoff between detection and handling:

What detection provides to handling:

When the page fault handler begins execution, it has access to:

1. The faulting virtual address (from a special register like CR2)
2. The fault type (encoded in an error code)
3. The saved processor state (registers, flags, instruction pointer)
4. The access type (read, write, or execute)
5. The privilege level (user mode or kernel mode)

This information is everything the OS needs to begin its analysis. The hardware's job is done—it has detected the condition and preserved enough state for software to handle it.