Operating SystemsInterrupts

Interrupts: Hardware-Level I/O Signaling

LevelIntermediate

Duration90 mins

TopicInterrupts

3 / 5

Interrupt Vector Table

Mapping Signals to Handlers

When an interrupt occurs, the CPU must instantly determine where to jump—which handler should process this specific interrupt? With potentially hundreds of different interrupt sources (hardware devices, exceptions, software traps), the CPU needs a fast, reliable lookup mechanism.

The Interrupt Vector Table (IVT) (or its more sophisticated cousin, the Interrupt Descriptor Table (IDT)) provides exactly this capability. It's a data structure in memory that the CPU consults during every interrupt, using the interrupt number as an index to find the handler's address. Understanding this mechanism is essential for anyone working at the systems level—from operating system developers to security researchers analyzing exploits.

What You Will Learn

By the end of this page, you will understand the fundamental design of interrupt vector tables, master the differences between real-mode IVT and protected-mode IDT on x86, learn how the CPU uses these tables during interrupt dispatch, and explore Linux's approach to populating and managing the IDT.

The Concept of an Interrupt Vector

An interrupt vector is simply a number that uniquely identifies a specific interrupt source or type. When hardware or software generates an interrupt, it provides a vector number that tells the CPU what kind of interrupt occurred.

The Vector Space:

Most CPUs define a fixed vector space—a range of possible interrupt numbers. On x86, this space contains 256 vectors (0-255). Each vector can be assigned to a specific purpose:

x86 Vector Number Assignments
Vector Range	Assignment	Description
0-31	CPU Exceptions	Divide error, page fault, double fault, etc.
32-127	External Interrupts	Timer, keyboard, disk, network, etc.
128 (0x80)	System Call	Linux traditionally uses INT 0x80
129-238	More IRQs / MSI	Additional device interrupts
239	APIC Spurious	Spurious interrupt handling
240-249	Reserved	Reserved for system use
250-255	IPI (Multi-CPU)	Inter-processor interrupts

The Vector Number as an Index:

The brilliance of the vector table design is its simplicity: the vector number is used directly as an index into an array. No searching, no hashing—just a constant-time array lookup.

If the table starts at address BASE and each entry is SIZE bytes:

Handler Address = Table[Vector] = Memory[BASE + (Vector × SIZE)]

This constant-time lookup is critical because interrupt dispatch happens millions of times per second. Any complexity here would devastate system performance.

Terminology Variations

Different architectures use different terms: x86 real mode has the Interrupt Vector Table (IVT), x86 protected mode uses the Interrupt Descriptor Table (IDT), ARM has the Vector Table (reset/exception vectors) plus the Generic Interrupt Controller (GIC), and RISC-V uses the machine trap-vector register (mtvec). The core concept—mapping interrupt numbers to handlers—remains consistent.

x86 Real Mode: The Original IVT

The x86 processor's real mode (used during boot and in legacy systems) implements the simplest form of interrupt vectoring. Understanding this design provides historical context and insight into why the protected-mode IDT evolved.

IVT Structure:

Location: Fixed at physical address 0x00000000
Size: 256 entries × 4 bytes = 1024 bytes (1 KB)
Entry Format: Each entry is a 4-byte far pointer (segment:offset)

The first 1 KB of memory in any x86 system booting in real mode is reserved for the IVT. The BIOS populates it with default handlers during POST (Power-On Self-Test).

real_mode_ivt.asm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
; x86 Real Mode Interrupt Vector Table Structure
;
; Memory Map:
; 0x00000 - 0x003FF : Interrupt Vector Table (256 × 4 bytes)
; Each entry: [Offset (2 bytes)] [Segment (2 bytes)]
;
; Vector 0:  0x0000-0x0003  Handler for Divide Error
; Vector 1:  0x0004-0x0007  Handler for Debug Exception
; Vector 2:  0x0008-0x000B  Handler for NMI
; Vector 3:  0x000C-0x000F  Handler for Breakpoint
; ...
; Vector 255: 0x03FC-0x03FF  Last vector
 
; Example: Reading the keyboard interrupt handler address (Vector 9)
; 
; Address = 0x0000 + (9 × 4) = 0x0024
; Value at 0x0024: Offset (word)
; Value at 0x0026: Segment (word)
; Handler Address = Segment:Offset = (Segment << 4) + Offset
 
; Installing a custom interrupt handler in real mode
install_keyboard_handler:
    ; Disable interrupts during modification
    cli
    
    ; Save old handler (for chaining)
    xor ax, ax
    mov es, ax                  ; ES = 0 (segment for IVT)
    mov ax, [es:0x24]           ; Get old offset (vector 9)
    mov [old_offset], ax
    mov ax, [es:0x26]           ; Get old segment
    mov [old_segment], ax
    
    ; Install new handler
    mov word [es:0x24], new_keyboard_handler
    mov word [es:0x26], cs      ; Current code segment
    
    ; Re-enable interrupts
    sti
    ret
 
new_keyboard_handler:
    ; Our custom keyboard handling code
    push ax
    in al, 0x60                 ; Read scancode from keyboard
    ; ... process keystroke ...
    pop ax
    
    ; Chain to original handler
    jmp far [old_handler]       ; Jump to old_segment:old_offset
 
section .data
old_handler:
    old_offset dw 0
    old_segment dw 0

CPU Interrupt Dispatch in Real Mode:

When an interrupt with vector N occurs:

CPU pushes FLAGS onto stack
CPU clears IF (interrupts disabled) and TF (trap flag)
CPU pushes CS onto stack
CPU pushes IP onto stack
CPU reads new IP from address N × 4
CPU reads new CS from address N × 4 + 2
Execution continues at CS:IP (the handler)

Limitations of Real Mode IVT:

Real Mode IVT Limitations

•No Protection: Any code can modify the IVT—no privilege checks
•No Privilege Transition: Cannot enforce kernel vs. user mode distinction
•16-bit Addresses Only: Limited to 1 MB address space (20-bit real mode)
•Fixed Location: IVT must be at address 0; cannot relocate
•No Error Codes: No mechanism to push error information on stack

Historical Note

The real-mode IVT design dates to the original 8086 processor (1978). Its simplicity was intentional—transistor counts were precious, and complex memory protection wasn't yet a priority. The design remained unchanged through the 80286 for backward compatibility and still exists in modern CPUs during initial boot.

x86 Protected Mode: The Interrupt Descriptor Table

Protected mode (introduced with the 80286 and fully realized in the 80386) replaced the simple IVT with the Interrupt Descriptor Table (IDT)—a more sophisticated structure that integrates with the CPU's memory protection and privilege mechanisms.

Key Differences from IVT:

Relocatable: The IDT can be placed anywhere in memory
Variable Size: Can have fewer than 256 entries
Rich Entries: Each entry (descriptor) contains protection information
Privilege Checks: CPU enforces privilege level transitions
32/64-bit Addresses: Full address space support

idt_structure.h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// x86-64 Interrupt Descriptor Table Structures
 
// The IDTR register points to the IDT
struct idtr {
    uint16_t limit;        // Size of IDT in bytes - 1
    uint64_t base;         // Linear address of IDT
} __attribute__((packed));
 
// 64-bit IDT Gate Descriptor (16 bytes per entry)
struct idt_gate_64 {
    uint16_t offset_low;        // Handler address bits 0-15
    uint16_t segment_selector;  // Code segment selector (usually kernel CS)
    uint8_t  ist;               // Interrupt Stack Table index (bits 0-2)
                                // Reserved bits 3-7
    uint8_t  type_attr;         // Gate type and attributes
                                // Bits 0-3: Gate Type (0xE = 64-bit interrupt gate)
                                // Bit 4: 0 (reserved)
                                // Bits 5-6: DPL (Descriptor Privilege Level)
                                // Bit 7: Present bit
    uint16_t offset_mid;        // Handler address bits 16-31
    uint32_t offset_high;       // Handler address bits 32-63
    uint32_t reserved;          // Must be zero
} __attribute__((packed));
 
// Gate types
#define GATE_INTERRUPT_32    0x8E  // 32-bit interrupt gate, DPL=0
#define GATE_INTERRUPT_64    0x8E  // 64-bit interrupt gate, DPL=0
#define GATE_TRAP_32         0x8F  // 32-bit trap gate, DPL=0
#define GATE_TRAP_64         0x8F  // 64-bit trap gate, DPL=0
#define GATE_SYSCALL         0xEE  // Interrupt gate, DPL=3 (user can call)
 
// Complete IDT - 256 entries, each 16 bytes
struct idt_gate_64 idt[256];
struct idtr idt_ptr;
 
// Load the IDT into the CPU
static inline void load_idt(void) {
    idt_ptr.limit = sizeof(idt) - 1;
    idt_ptr.base = (uint64_t)&idt;
    
    asm volatile("lidt %0" : : "m"(idt_ptr));
}
 
// Set up an IDT entry
void set_idt_gate(uint8_t vector, void (*handler)(void), 
                  uint16_t selector, uint8_t type_attr, uint8_t ist) {
    uint64_t addr = (uint64_t)handler;
    
    idt[vector].offset_low  = addr & 0xFFFF;
    idt[vector].offset_mid  = (addr >> 16) & 0xFFFF;
    idt[vector].offset_high = (addr >> 32) & 0xFFFFFFFF;
    idt[vector].segment_selector = selector;
    idt[vector].ist = ist & 0x7;
    idt[vector].type_attr = type_attr;
    idt[vector].reserved = 0;
}

IDT Descriptor Fields Explained:

Offset (Handler Address): Split across three fields for historical reasons (16-bit, then 32-bit, then 64-bit extensions). Combined, they form the full 64-bit handler address.

Segment Selector: Points to a code segment descriptor in the GDT. For kernel interrupt handlers, this is typically the kernel code segment with DPL=0.

DPL (Descriptor Privilege Level): Determines who can trigger this interrupt via software (INT instruction). For hardware interrupts, DPL doesn't matter. For software traps like system calls, DPL=3 allows user code to execute INT n.

IST (Interrupt Stack Table): x86-64 feature allowing specific interrupts to use predetermined stacks. Critical for handling double faults and NMIs where the current stack may be corrupted.

IDT Gate Types
Gate Type	IF After Entry	Use Case
Interrupt Gate (0xE)	Cleared (interrupts disabled)	Hardware IRQs, exceptions needing atomicity
Trap Gate (0xF)	Unchanged	Debugger breakpoints, some exceptions

Critical Security Point

The DPL field is a security barrier. If a software interrupt's gate has DPL=0, user-mode code cannot trigger it via INT n—the CPU will raise a General Protection Fault. This is why INT 0x80 (Linux syscall) has DPL=3 but INT 0 (divide error) has DPL=0. An attacker cannot directly invoke exception handlers.

CPU Interrupt Dispatch via IDT

When an interrupt occurs in protected mode, the CPU performs a complex sequence of validation, privilege checking, and state saving before transferring control. This sequence is hardwired into the processor.

Complete Interrupt Dispatch Sequence (x86-64):

Converting Mermaid diagram...

Stack Frame After Interrupt (x86-64):

After the CPU completes its automatic push sequence, the stack contains:

interrupt_stack_frame.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
/*
 * x86-64 Interrupt Stack Frame
 * (addresses increase downward, stack grows up)
 *
 * If privilege level changes (ring 3 → ring 0):
 *
 *     +40: SS                    (old stack segment)
 *     +32: RSP                   (old stack pointer)
 *     +24: RFLAGS                (processor flags)
 *     +16: CS                    (old code segment)
 *     +8:  RIP                   (return address)
 *     +0:  Error Code            (if applicable, CPU pushes)
 *   ----> RSP points here when handler starts
 *
 * If same privilege level:
 *
 *     +24: RFLAGS
 *     +16: CS
 *     +8:  RIP
 *     +0:  Error Code (if applicable)
 *   ----> RSP points here when handler starts
 */
 
// C structure matching the interrupt stack frame
struct interrupt_frame {
    uint64_t rip;       // Instruction to return to
    uint64_t cs;        // Code segment
    uint64_t rflags;    // Processor flags
    uint64_t rsp;       // Stack pointer (only if ring change)
    uint64_t ss;        // Stack segment (only if ring change)
};
 
// For exceptions with error codes (page fault, GP fault, etc.)
struct interrupt_frame_with_error {
    uint64_t error_code;  // Pushed by CPU
    uint64_t rip;
    uint64_t cs;
    uint64_t rflags;
    uint64_t rsp;
    uint64_t ss;
};

The IRET Instruction

The IRET (Interrupt Return) instruction reverses this entire process atomically. It pops RIP, CS, RFLAGS (and RSP, SS if returning to a different privilege level), restoring the interrupted context. The atomicity is crucial—no window exists where state is partially restored.

The Interrupt Stack Table (IST)

x86-64 introduced the Interrupt Stack Table (IST)—a mechanism to unconditionally switch to a known-good stack during interrupt handling. This solves a critical chicken-and-egg problem: what if the current stack is corrupted or exhausted, and we receive an interrupt?

The Problem IST Solves:

Consider a stack overflow in kernel code. The stack pointer now points to invalid memory. If an interrupt arrives:

CPU tries to push data to the stack
Stack is invalid → second fault occurs
CPU tries to push the fault → third fault
Result: Triple Fault → immediate CPU reset

With IST, specific interrupts (like NMI, double fault, machine check) can switch to a pre-configured, known-good stack unconditionally.

ist_setup.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// Interrupt Stack Table Setup in x86-64
 
// The TSS (Task State Segment) contains IST entries
struct tss64 {
    uint32_t reserved0;
    uint64_t rsp0;       // Stack for ring 0 (used for privilege changes)
    uint64_t rsp1;       // Stack for ring 1 (rarely used)
    uint64_t rsp2;       // Stack for ring 2 (rarely used)
    uint64_t reserved1;
    uint64_t ist[7];     // Interrupt Stack Table entries 1-7
                         // (IST index 0 in gate descriptor means "use normal rules")
    uint64_t reserved2;
    uint16_t reserved3;
    uint16_t iopb_offset; // I/O Permission Bitmap offset
} __attribute__((packed));
 
// Linux IST stack assignments
#define IST_DOUBLEFAULT    1   // Double fault handler
#define IST_NMI            2   // Non-maskable interrupt
#define IST_DEBUG          3   // Debug exceptions
#define IST_MCE            4   // Machine check exceptions
 
// Allocate IST stacks (per-CPU)
DEFINE_PER_CPU(unsigned long, ist_doublefault_stack[8192/sizeof(long)]);
DEFINE_PER_CPU(unsigned long, ist_nmi_stack[8192/sizeof(long)]);
DEFINE_PER_CPU(unsigned long, ist_debug_stack[8192/sizeof(long)]);
DEFINE_PER_CPU(unsigned long, ist_mce_stack[8192/sizeof(long)]);
 
// Initialize TSS IST entries for this CPU
void init_tss_ist(int cpu) {
    struct tss64 *tss = &per_cpu(cpu_tss, cpu);
    
    // IST stacks grow downward, so point to top of allocated region
    tss->ist[IST_DOUBLEFAULT - 1] = 
        (unsigned long)&per_cpu(ist_doublefault_stack, cpu) + sizeof(ist_doublefault_stack);
    tss->ist[IST_NMI - 1] = 
        (unsigned long)&per_cpu(ist_nmi_stack, cpu) + sizeof(ist_nmi_stack);
    tss->ist[IST_DEBUG - 1] = 
        (unsigned long)&per_cpu(ist_debug_stack, cpu) + sizeof(ist_debug_stack);
    tss->ist[IST_MCE - 1] = 
        (unsigned long)&per_cpu(ist_mce_stack, cpu) + sizeof(ist_mce_stack);
}
 
// Configuring an IDT gate to use IST
void set_ist_gate(uint8_t vector, void *handler, uint8_t ist_index) {
    // Set up normal gate fields...
    idt[vector].offset_low = (uint64_t)handler & 0xFFFF;
    idt[vector].segment_selector = KERNEL_CS;
    idt[vector].type_attr = GATE_INTERRUPT_64;
    idt[vector].offset_mid = ((uint64_t)handler >> 16) & 0xFFFF;
    idt[vector].offset_high = (uint64_t)handler >> 32;
    
    // Set IST index (1-7, or 0 for normal stack behavior)
    idt[vector].ist = ist_index;  
}
 
// During boot:
set_ist_gate(8,  double_fault_handler, IST_DOUBLEFAULT);
set_ist_gate(2,  nmi_handler,          IST_NMI);
set_ist_gate(1,  debug_handler,        IST_DEBUG);
set_ist_gate(18, machine_check_handler, IST_MCE);

Interrupts Typically Using IST

•Double Fault (Vector 8): Can occur when handling another exception with a bad stack
•NMI (Vector 2): Non-maskable, can arrive at any time, even during exception handling
•Debug Exception (Vector 1): May occur during kernel code at arbitrary points
•Machine Check (Vector 18): Hardware errors can occur at any moment

IST Stack Nesting Danger

IST has a critical limitation: if the same IST interrupt occurs while its handler is running, the second interrupt will overwrite the first's stack frame (same stack pointer loaded unconditionally). Linux addresses this for NMI by carefully structuring the NMI handler and using a technique called 'NMI nesting' that copies the frame before enabling further NMIs.

Linux IDT Initialization

Linux sets up the IDT during early boot, populating it with handlers for CPU exceptions, hardware interrupts, and system calls. Understanding this initialization illuminates how the kernel takes control of the interrupt mechanism.

Boot-Time IDT Setup:

linux_idt_init.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// Simplified view of Linux IDT initialization (arch/x86/kernel/idt.c)
 
// Exception entries (vectors 0-31)
static const struct idt_entry exception_table[] = {
    // Vector  Handler              IST   DPL
    { 0,       divide_error,        0,    0 },   // #DE Divide Error
    { 1,       debug,               IST_DB, 0 }, // #DB Debug
    { 2,       nmi,                 IST_NMI, 0 }, // NMI
    { 3,       int3,                0,    3 },   // #BP Breakpoint (DPL=3 for user)
    { 4,       overflow,            0,    0 },   // #OF Overflow
    { 5,       bounds,              0,    0 },   // #BR Bound Range
    { 6,       invalid_op,          0,    0 },   // #UD Invalid Opcode
    { 7,       device_not_available, 0,   0 },   // #NM Device Not Available
    { 8,       double_fault,        IST_DF, 0 }, // #DF Double Fault
    { 10,      invalid_TSS,         0,    0 },   // #TS Invalid TSS
    { 11,      segment_not_present, 0,    0 },   // #NP Segment Not Present
    { 12,      stack_segment,       0,    0 },   // #SS Stack Fault
    { 13,      general_protection,  0,    0 },   // #GP General Protection
    { 14,      page_fault,          0,    0 },   // #PF Page Fault
    { 16,      coprocessor_error,   0,    0 },   // #MF x87 FP Error
    { 17,      alignment_check,     0,    0 },   // #AC Alignment Check
    { 18,      machine_check,       IST_MCE, 0 },// #MC Machine Check
    { 19,      simd_coprocessor_error, 0, 0 },   // #XM SIMD Exception
    { 20,      virtualization_exception, 0, 0 }, // #VE Virtualization
    // ... more exceptions ...
};
 
// Hardware IRQ entries (vectors 32-255)
// Most are initially set to a common stub, then configured per-device
 
// System call entry (traditional INT 0x80)
static const struct idt_entry syscall_entry = {
    .vector = 0x80,
    .handler = entry_INT80_compat,
    .ist = 0,
    .dpl = 3,   // User space can trigger INT 0x80
};
 
// Main initialization function
void __init idt_setup_early_traps(void) {
    // Load exception handlers (critical path)
    for (int i = 0; i < ARRAY_SIZE(exception_table); i++) {
        set_idt_gate(exception_table[i].vector,
                     exception_table[i].handler,
                     KERNEL_CS,
                     gate_type(exception_table[i].dpl),
                     exception_table[i].ist);
    }
    
    // Load the IDT register
    load_idt();
}
 
void __init idt_setup_traps(void) {
    // Set up remaining handlers after early boot
    set_idt_gate(0x80, entry_INT80_compat, KERNEL_CS, 
                 GATE_SYSCALL, 0);  // DPL=3 for syscall
}
 
void __init idt_setup_apic(void) {
    // Set up APIC interrupt vectors
    for_each_possible_cpu(cpu) {
        set_handler_irq(LOCAL_TIMER_VECTOR, local_apic_timer_interrupt);
        set_handler_irq(SPURIOUS_APIC_VECTOR, spurious_interrupt);
        // ... more APIC vectors ...
    }
}
 
void __init idt_setup_ist_traps(void) {
    // Configure IST stack assignments
    set_ist_gate(2,  nmi, IST_NMI);
    set_ist_gate(1,  debug, IST_DB);
    set_ist_gate(8,  double_fault, IST_DF);
    set_ist_gate(18, machine_check, IST_MCE);
}

The IDT Lifecycle:

Early Boot: A minimal IDT with exception handlers is set up in assembly very early
Trap Setup: CPU exception handlers are fully configured
IRQ Setup: Hardware interrupt vectors are configured (initially to stubs)
Device Driver Load: Drivers request IRQs and their handlers are associated with vectors
Runtime: IDT is rarely modified after boot (mostly static)

Viewing the Current IDT:

viewing_idt.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# View interrupt handlers and stats in Linux
 
# Current interrupt counts per CPU and IRQ
$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:         22          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          9   IO-APIC   1-edge      i8042
  8:          0          0          0          0   IO-APIC   8-edge      rtc0
  9:          0          4          0          0   IO-APIC   9-fasteoi   acpi
 16:          0          0          0          0   IO-APIC  16-fasteoi   ehci_hcd
 23:        156          0          0          0   IO-APIC  23-fasteoi   ehci_hcd
 24:          0          0          0          0   PCI-MSI 327680-edge   xhci_hcd
 25:          0       1892          0          0   PCI-MSI 512000-edge   ahci
 26:          0          0      12487          0   PCI-MSI 1048576-edge  nvme0q0
 27:          0          0          0      89432   PCI-MSI 1048577-edge  nvme0q1
NMI:          0          0          0          0   Non-maskable interrupts
LOC:     123456     118234     125678     119087   Local timer interrupts
...
 
# More detailed IRQ information
$ ls /proc/irq/
0  1  10  11  12  13  14  15  16  17  18  19  2  20 ...
 
$ cat /proc/irq/25/smp_affinity
f    # All 4 CPUs can handle this IRQ (bitmask)
 
$ cat /proc/irq/25/affinity_hint
8    # Hint: CPU 3 preferred (bitmask)

IDT Security

The kernel protects the IDT from modification by user-space code (it's in kernel memory) and by kernel modules using memory protection. Some security features like SMAP/SMEP add additional protection. Modern exploits targeting the IDT face multiple defensive layers.

Vector Tables on Other Architectures

While we've focused on x86, every processor architecture has some form of interrupt vector mechanism. Understanding the variations helps appreciate design trade-offs and prepares you for cross-platform work.

ARM Exception Vector Table:

ARM uses a fundamentally different approach. Instead of a table of addresses, ARM has a table of instructions at the vector location. Each exception type has exactly 4 bytes (one instruction), which is typically a branch to the actual handler.

ARMv7 and Earlier:

Vector table at address 0x00000000 (low vectors) or 0xFFFF0000 (high vectors)
Control via SCTLR.V bit

ARMv8 (AArch64):

Vector table address set via VBAR_ELn registers
16 entries × 128 bytes each = 2KB table
Entries grouped by exception level and state (synchronous, IRQ, FIQ, SError)

// ARMv8 exception vector table entry points
// Each entry point gets 128 bytes (32 instructions)
// Organized by target EL and source EL/SP

.align 11  // 2^11 = 2048 byte alignment
exception_vectors:
    // From same EL, using SP_EL0 (entries 0-3)
    b sync_current_el_sp0   // +0x000
    b irq_current_el_sp0    // +0x080
    b fiq_current_el_sp0    // +0x100
    b serror_current_el_sp0 // +0x180
    
    // From same EL, using SP_ELx (entries 4-7)
    b sync_current_el_spx   // +0x200
    b irq_current_el_spx    // +0x280
    // ... etc

Interrupt Vector Table Comparison Across Architectures
Feature	x86 (IDT)	ARM64	RISC-V
Table Location	Configurable (IDTR)	Configurable (VBAR_ELx)	Configurable (mtvec)
Entry Size	16 bytes	128 bytes	4 bytes (vectored)
Max Entries	256	16 (4 types × 4 source modes)	Varies
Entry Content	Descriptor (address + metadata)	Instructions (branch/code)	Instruction (jump)
Privilege Check	DPL in descriptor	Exception level inherent	CSR access controls

Summary: Interrupt Vector Tables

We've explored how processors map interrupt numbers to handler addresses. Let's consolidate the key takeaways:

Key Takeaways

•Vectors are indices into a table — The interrupt number serves as a direct index for constant-time handler lookup.
•Real mode IVT is simple but unprotected — 4-byte entries at address 0, no privilege checking, historical design.
•Protected mode IDT integrates with security — Rich descriptors include privilege levels, segment selectors, and per-entry stack selection.
•CPU performs extensive checks during dispatch — Bounds checking, DPL validation, privilege transitions, and automatic state saving.
•IST provides unconditional stack switching — Critical for handling faults when the current stack is corrupted.
•Linux initializes IDT during boot — Exception handlers first, then hardware IRQs, with IST for critical vectors.
•Different architectures, same concept — Whether x86 IDT, ARM vector table, or RISC-V mtvec, the goal is identical: fast mapping from interrupt number to handler.

What's Next:

With a solid understanding of how handlers are located, the next page explores interrupt priority—how systems determine which interrupt to service when multiple arrive simultaneously, and how priority affects handler preemption and overall system responsiveness.

Page Complete

You now understand the data structures that connect hardware interrupt signals to software handlers. The interrupt vector table is one of the most fundamental concepts in systems programming—it's how every device driver, every exception handler, and every system call enters the kernel.

3 / 5

Loading learning content...

Operating SystemsInterrupts

Interrupts: Hardware-Level I/O Signaling

LevelIntermediate

Duration90 mins

TopicInterrupts

3 / 5

Interrupt Vector Table

Mapping Signals to Handlers

What You Will Learn

The Concept of an Interrupt Vector

The Vector Space:

Most CPUs define a fixed vector space—a range of possible interrupt numbers. On x86, this space contains 256 vectors (0-255). Each vector can be assigned to a specific purpose:

x86 Vector Number Assignments
Vector Range	Assignment	Description
0-31	CPU Exceptions	Divide error, page fault, double fault, etc.
32-127	External Interrupts	Timer, keyboard, disk, network, etc.
128 (0x80)	System Call	Linux traditionally uses INT 0x80
129-238	More IRQs / MSI	Additional device interrupts
239	APIC Spurious	Spurious interrupt handling
240-249	Reserved	Reserved for system use
250-255	IPI (Multi-CPU)	Inter-processor interrupts

The Vector Number as an Index:

The brilliance of the vector table design is its simplicity: the vector number is used directly as an index into an array. No searching, no hashing—just a constant-time array lookup.

If the table starts at address BASE and each entry is SIZE bytes:

Handler Address = Table[Vector] = Memory[BASE + (Vector × SIZE)]

This constant-time lookup is critical because interrupt dispatch happens millions of times per second. Any complexity here would devastate system performance.

Terminology Variations

x86 Real Mode: The Original IVT

IVT Structure:

Location: Fixed at physical address 0x00000000
Size: 256 entries × 4 bytes = 1024 bytes (1 KB)
Entry Format: Each entry is a 4-byte far pointer (segment:offset)

The first 1 KB of memory in any x86 system booting in real mode is reserved for the IVT. The BIOS populates it with default handlers during POST (Power-On Self-Test).

real_mode_ivt.asm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
; x86 Real Mode Interrupt Vector Table Structure
;
; Memory Map:
; 0x00000 - 0x003FF : Interrupt Vector Table (256 × 4 bytes)
; Each entry: [Offset (2 bytes)] [Segment (2 bytes)]
;
; Vector 0:  0x0000-0x0003  Handler for Divide Error
; Vector 1:  0x0004-0x0007  Handler for Debug Exception
; Vector 2:  0x0008-0x000B  Handler for NMI
; Vector 3:  0x000C-0x000F  Handler for Breakpoint
; ...
; Vector 255: 0x03FC-0x03FF  Last vector
 
; Example: Reading the keyboard interrupt handler address (Vector 9)
; 
; Address = 0x0000 + (9 × 4) = 0x0024
; Value at 0x0024: Offset (word)
; Value at 0x0026: Segment (word)
; Handler Address = Segment:Offset = (Segment << 4) + Offset
 
; Installing a custom interrupt handler in real mode
install_keyboard_handler:
    ; Disable interrupts during modification
    cli
    
    ; Save old handler (for chaining)
    xor ax, ax
    mov es, ax                  ; ES = 0 (segment for IVT)
    mov ax, [es:0x24]           ; Get old offset (vector 9)
    mov [old_offset], ax
    mov ax, [es:0x26]           ; Get old segment
    mov [old_segment], ax
    
    ; Install new handler
    mov word [es:0x24], new_keyboard_handler
    mov word [es:0x26], cs      ; Current code segment
    
    ; Re-enable interrupts
    sti
    ret
 
new_keyboard_handler:
    ; Our custom keyboard handling code
    push ax
    in al, 0x60                 ; Read scancode from keyboard
    ; ... process keystroke ...
    pop ax
    
    ; Chain to original handler
    jmp far [old_handler]       ; Jump to old_segment:old_offset
 
section .data
old_handler:
    old_offset dw 0
    old_segment dw 0

CPU Interrupt Dispatch in Real Mode:

When an interrupt with vector N occurs:

CPU pushes FLAGS onto stack
CPU clears IF (interrupts disabled) and TF (trap flag)
CPU pushes CS onto stack
CPU pushes IP onto stack
CPU reads new IP from address N × 4
CPU reads new CS from address N × 4 + 2
Execution continues at CS:IP (the handler)

Limitations of Real Mode IVT:

Real Mode IVT Limitations

•No Protection: Any code can modify the IVT—no privilege checks
•No Privilege Transition: Cannot enforce kernel vs. user mode distinction
•16-bit Addresses Only: Limited to 1 MB address space (20-bit real mode)
•Fixed Location: IVT must be at address 0; cannot relocate
•No Error Codes: No mechanism to push error information on stack

Historical Note

x86 Protected Mode: The Interrupt Descriptor Table

Key Differences from IVT:

Relocatable: The IDT can be placed anywhere in memory
Variable Size: Can have fewer than 256 entries
Rich Entries: Each entry (descriptor) contains protection information
Privilege Checks: CPU enforces privilege level transitions
32/64-bit Addresses: Full address space support

idt_structure.h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// x86-64 Interrupt Descriptor Table Structures
 
// The IDTR register points to the IDT
struct idtr {
    uint16_t limit;        // Size of IDT in bytes - 1
    uint64_t base;         // Linear address of IDT
} __attribute__((packed));
 
// 64-bit IDT Gate Descriptor (16 bytes per entry)
struct idt_gate_64 {
    uint16_t offset_low;        // Handler address bits 0-15
    uint16_t segment_selector;  // Code segment selector (usually kernel CS)
    uint8_t  ist;               // Interrupt Stack Table index (bits 0-2)
                                // Reserved bits 3-7
    uint8_t  type_attr;         // Gate type and attributes
                                // Bits 0-3: Gate Type (0xE = 64-bit interrupt gate)
                                // Bit 4: 0 (reserved)
                                // Bits 5-6: DPL (Descriptor Privilege Level)
                                // Bit 7: Present bit
    uint16_t offset_mid;        // Handler address bits 16-31
    uint32_t offset_high;       // Handler address bits 32-63
    uint32_t reserved;          // Must be zero
} __attribute__((packed));
 
// Gate types
#define GATE_INTERRUPT_32    0x8E  // 32-bit interrupt gate, DPL=0
#define GATE_INTERRUPT_64    0x8E  // 64-bit interrupt gate, DPL=0
#define GATE_TRAP_32         0x8F  // 32-bit trap gate, DPL=0
#define GATE_TRAP_64         0x8F  // 64-bit trap gate, DPL=0
#define GATE_SYSCALL         0xEE  // Interrupt gate, DPL=3 (user can call)
 
// Complete IDT - 256 entries, each 16 bytes
struct idt_gate_64 idt[256];
struct idtr idt_ptr;
 
// Load the IDT into the CPU
static inline void load_idt(void) {
    idt_ptr.limit = sizeof(idt) - 1;
    idt_ptr.base = (uint64_t)&idt;
    
    asm volatile("lidt %0" : : "m"(idt_ptr));
}
 
// Set up an IDT entry
void set_idt_gate(uint8_t vector, void (*handler)(void), 
                  uint16_t selector, uint8_t type_attr, uint8_t ist) {
    uint64_t addr = (uint64_t)handler;
    
    idt[vector].offset_low  = addr & 0xFFFF;
    idt[vector].offset_mid  = (addr >> 16) & 0xFFFF;
    idt[vector].offset_high = (addr >> 32) & 0xFFFFFFFF;
    idt[vector].segment_selector = selector;
    idt[vector].ist = ist & 0x7;
    idt[vector].type_attr = type_attr;
    idt[vector].reserved = 0;
}

IDT Descriptor Fields Explained:

Offset (Handler Address): Split across three fields for historical reasons (16-bit, then 32-bit, then 64-bit extensions). Combined, they form the full 64-bit handler address.

Segment Selector: Points to a code segment descriptor in the GDT. For kernel interrupt handlers, this is typically the kernel code segment with DPL=0.

IST (Interrupt Stack Table): x86-64 feature allowing specific interrupts to use predetermined stacks. Critical for handling double faults and NMIs where the current stack may be corrupted.

IDT Gate Types
Gate Type	IF After Entry	Use Case
Interrupt Gate (0xE)	Cleared (interrupts disabled)	Hardware IRQs, exceptions needing atomicity
Trap Gate (0xF)	Unchanged	Debugger breakpoints, some exceptions

Critical Security Point

CPU Interrupt Dispatch via IDT

Complete Interrupt Dispatch Sequence (x86-64):

Converting Mermaid diagram...

Stack Frame After Interrupt (x86-64):

After the CPU completes its automatic push sequence, the stack contains:

interrupt_stack_frame.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
/*
 * x86-64 Interrupt Stack Frame
 * (addresses increase downward, stack grows up)
 *
 * If privilege level changes (ring 3 → ring 0):
 *
 *     +40: SS                    (old stack segment)
 *     +32: RSP                   (old stack pointer)
 *     +24: RFLAGS                (processor flags)
 *     +16: CS                    (old code segment)
 *     +8:  RIP                   (return address)
 *     +0:  Error Code            (if applicable, CPU pushes)
 *   ----> RSP points here when handler starts
 *
 * If same privilege level:
 *
 *     +24: RFLAGS
 *     +16: CS
 *     +8:  RIP
 *     +0:  Error Code (if applicable)
 *   ----> RSP points here when handler starts
 */
 
// C structure matching the interrupt stack frame
struct interrupt_frame {
    uint64_t rip;       // Instruction to return to
    uint64_t cs;        // Code segment
    uint64_t rflags;    // Processor flags
    uint64_t rsp;       // Stack pointer (only if ring change)
    uint64_t ss;        // Stack segment (only if ring change)
};
 
// For exceptions with error codes (page fault, GP fault, etc.)
struct interrupt_frame_with_error {
    uint64_t error_code;  // Pushed by CPU
    uint64_t rip;
    uint64_t cs;
    uint64_t rflags;
    uint64_t rsp;
    uint64_t ss;
};

The IRET Instruction

The Interrupt Stack Table (IST)

The Problem IST Solves:

Consider a stack overflow in kernel code. The stack pointer now points to invalid memory. If an interrupt arrives:

CPU tries to push data to the stack
Stack is invalid → second fault occurs
CPU tries to push the fault → third fault
Result: Triple Fault → immediate CPU reset

With IST, specific interrupts (like NMI, double fault, machine check) can switch to a pre-configured, known-good stack unconditionally.

ist_setup.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// Interrupt Stack Table Setup in x86-64
 
// The TSS (Task State Segment) contains IST entries
struct tss64 {
    uint32_t reserved0;
    uint64_t rsp0;       // Stack for ring 0 (used for privilege changes)
    uint64_t rsp1;       // Stack for ring 1 (rarely used)
    uint64_t rsp2;       // Stack for ring 2 (rarely used)
    uint64_t reserved1;
    uint64_t ist[7];     // Interrupt Stack Table entries 1-7
                         // (IST index 0 in gate descriptor means "use normal rules")
    uint64_t reserved2;
    uint16_t reserved3;
    uint16_t iopb_offset; // I/O Permission Bitmap offset
} __attribute__((packed));
 
// Linux IST stack assignments
#define IST_DOUBLEFAULT    1   // Double fault handler
#define IST_NMI            2   // Non-maskable interrupt
#define IST_DEBUG          3   // Debug exceptions
#define IST_MCE            4   // Machine check exceptions
 
// Allocate IST stacks (per-CPU)
DEFINE_PER_CPU(unsigned long, ist_doublefault_stack[8192/sizeof(long)]);
DEFINE_PER_CPU(unsigned long, ist_nmi_stack[8192/sizeof(long)]);
DEFINE_PER_CPU(unsigned long, ist_debug_stack[8192/sizeof(long)]);
DEFINE_PER_CPU(unsigned long, ist_mce_stack[8192/sizeof(long)]);
 
// Initialize TSS IST entries for this CPU
void init_tss_ist(int cpu) {
    struct tss64 *tss = &per_cpu(cpu_tss, cpu);
    
    // IST stacks grow downward, so point to top of allocated region
    tss->ist[IST_DOUBLEFAULT - 1] = 
        (unsigned long)&per_cpu(ist_doublefault_stack, cpu) + sizeof(ist_doublefault_stack);
    tss->ist[IST_NMI - 1] = 
        (unsigned long)&per_cpu(ist_nmi_stack, cpu) + sizeof(ist_nmi_stack);
    tss->ist[IST_DEBUG - 1] = 
        (unsigned long)&per_cpu(ist_debug_stack, cpu) + sizeof(ist_debug_stack);
    tss->ist[IST_MCE - 1] = 
        (unsigned long)&per_cpu(ist_mce_stack, cpu) + sizeof(ist_mce_stack);
}
 
// Configuring an IDT gate to use IST
void set_ist_gate(uint8_t vector, void *handler, uint8_t ist_index) {
    // Set up normal gate fields...
    idt[vector].offset_low = (uint64_t)handler & 0xFFFF;
    idt[vector].segment_selector = KERNEL_CS;
    idt[vector].type_attr = GATE_INTERRUPT_64;
    idt[vector].offset_mid = ((uint64_t)handler >> 16) & 0xFFFF;
    idt[vector].offset_high = (uint64_t)handler >> 32;
    
    // Set IST index (1-7, or 0 for normal stack behavior)
    idt[vector].ist = ist_index;  
}
 
// During boot:
set_ist_gate(8,  double_fault_handler, IST_DOUBLEFAULT);
set_ist_gate(2,  nmi_handler,          IST_NMI);
set_ist_gate(1,  debug_handler,        IST_DEBUG);
set_ist_gate(18, machine_check_handler, IST_MCE);

Interrupts Typically Using IST

•Double Fault (Vector 8): Can occur when handling another exception with a bad stack
•NMI (Vector 2): Non-maskable, can arrive at any time, even during exception handling
•Debug Exception (Vector 1): May occur during kernel code at arbitrary points
•Machine Check (Vector 18): Hardware errors can occur at any moment

IST Stack Nesting Danger

Linux IDT Initialization

Boot-Time IDT Setup:

linux_idt_init.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// Simplified view of Linux IDT initialization (arch/x86/kernel/idt.c)
 
// Exception entries (vectors 0-31)
static const struct idt_entry exception_table[] = {
    // Vector  Handler              IST   DPL
    { 0,       divide_error,        0,    0 },   // #DE Divide Error
    { 1,       debug,               IST_DB, 0 }, // #DB Debug
    { 2,       nmi,                 IST_NMI, 0 }, // NMI
    { 3,       int3,                0,    3 },   // #BP Breakpoint (DPL=3 for user)
    { 4,       overflow,            0,    0 },   // #OF Overflow
    { 5,       bounds,              0,    0 },   // #BR Bound Range
    { 6,       invalid_op,          0,    0 },   // #UD Invalid Opcode
    { 7,       device_not_available, 0,   0 },   // #NM Device Not Available
    { 8,       double_fault,        IST_DF, 0 }, // #DF Double Fault
    { 10,      invalid_TSS,         0,    0 },   // #TS Invalid TSS
    { 11,      segment_not_present, 0,    0 },   // #NP Segment Not Present
    { 12,      stack_segment,       0,    0 },   // #SS Stack Fault
    { 13,      general_protection,  0,    0 },   // #GP General Protection
    { 14,      page_fault,          0,    0 },   // #PF Page Fault
    { 16,      coprocessor_error,   0,    0 },   // #MF x87 FP Error
    { 17,      alignment_check,     0,    0 },   // #AC Alignment Check
    { 18,      machine_check,       IST_MCE, 0 },// #MC Machine Check
    { 19,      simd_coprocessor_error, 0, 0 },   // #XM SIMD Exception
    { 20,      virtualization_exception, 0, 0 }, // #VE Virtualization
    // ... more exceptions ...
};
 
// Hardware IRQ entries (vectors 32-255)
// Most are initially set to a common stub, then configured per-device
 
// System call entry (traditional INT 0x80)
static const struct idt_entry syscall_entry = {
    .vector = 0x80,
    .handler = entry_INT80_compat,
    .ist = 0,
    .dpl = 3,   // User space can trigger INT 0x80
};
 
// Main initialization function
void __init idt_setup_early_traps(void) {
    // Load exception handlers (critical path)
    for (int i = 0; i < ARRAY_SIZE(exception_table); i++) {
        set_idt_gate(exception_table[i].vector,
                     exception_table[i].handler,
                     KERNEL_CS,
                     gate_type(exception_table[i].dpl),
                     exception_table[i].ist);
    }
    
    // Load the IDT register
    load_idt();
}
 
void __init idt_setup_traps(void) {
    // Set up remaining handlers after early boot
    set_idt_gate(0x80, entry_INT80_compat, KERNEL_CS, 
                 GATE_SYSCALL, 0);  // DPL=3 for syscall
}
 
void __init idt_setup_apic(void) {
    // Set up APIC interrupt vectors
    for_each_possible_cpu(cpu) {
        set_handler_irq(LOCAL_TIMER_VECTOR, local_apic_timer_interrupt);
        set_handler_irq(SPURIOUS_APIC_VECTOR, spurious_interrupt);
        // ... more APIC vectors ...
    }
}
 
void __init idt_setup_ist_traps(void) {
    // Configure IST stack assignments
    set_ist_gate(2,  nmi, IST_NMI);
    set_ist_gate(1,  debug, IST_DB);
    set_ist_gate(8,  double_fault, IST_DF);
    set_ist_gate(18, machine_check, IST_MCE);
}

The IDT Lifecycle:

Early Boot: A minimal IDT with exception handlers is set up in assembly very early
Trap Setup: CPU exception handlers are fully configured
IRQ Setup: Hardware interrupt vectors are configured (initially to stubs)
Device Driver Load: Drivers request IRQs and their handlers are associated with vectors
Runtime: IDT is rarely modified after boot (mostly static)

Viewing the Current IDT:

viewing_idt.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# View interrupt handlers and stats in Linux
 
# Current interrupt counts per CPU and IRQ
$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:         22          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          9   IO-APIC   1-edge      i8042
  8:          0          0          0          0   IO-APIC   8-edge      rtc0
  9:          0          4          0          0   IO-APIC   9-fasteoi   acpi
 16:          0          0          0          0   IO-APIC  16-fasteoi   ehci_hcd
 23:        156          0          0          0   IO-APIC  23-fasteoi   ehci_hcd
 24:          0          0          0          0   PCI-MSI 327680-edge   xhci_hcd
 25:          0       1892          0          0   PCI-MSI 512000-edge   ahci
 26:          0          0      12487          0   PCI-MSI 1048576-edge  nvme0q0
 27:          0          0          0      89432   PCI-MSI 1048577-edge  nvme0q1
NMI:          0          0          0          0   Non-maskable interrupts
LOC:     123456     118234     125678     119087   Local timer interrupts
...
 
# More detailed IRQ information
$ ls /proc/irq/
0  1  10  11  12  13  14  15  16  17  18  19  2  20 ...
 
$ cat /proc/irq/25/smp_affinity
f    # All 4 CPUs can handle this IRQ (bitmask)
 
$ cat /proc/irq/25/affinity_hint
8    # Hint: CPU 3 preferred (bitmask)

IDT Security

Vector Tables on Other Architectures

ARM Exception Vector Table:

ARMv7 and Earlier:

Vector table at address 0x00000000 (low vectors) or 0xFFFF0000 (high vectors)
Control via SCTLR.V bit

ARMv8 (AArch64):

Vector table address set via VBAR_ELn registers
16 entries × 128 bytes each = 2KB table
Entries grouped by exception level and state (synchronous, IRQ, FIQ, SError)

// ARMv8 exception vector table entry points
// Each entry point gets 128 bytes (32 instructions)
// Organized by target EL and source EL/SP

.align 11  // 2^11 = 2048 byte alignment
exception_vectors:
    // From same EL, using SP_EL0 (entries 0-3)
    b sync_current_el_sp0   // +0x000
    b irq_current_el_sp0    // +0x080
    b fiq_current_el_sp0    // +0x100
    b serror_current_el_sp0 // +0x180
    
    // From same EL, using SP_ELx (entries 4-7)
    b sync_current_el_spx   // +0x200
    b irq_current_el_spx    // +0x280
    // ... etc

Interrupt Vector Table Comparison Across Architectures
Feature	x86 (IDT)	ARM64	RISC-V
Table Location	Configurable (IDTR)	Configurable (VBAR_ELx)	Configurable (mtvec)
Entry Size	16 bytes	128 bytes	4 bytes (vectored)
Max Entries	256	16 (4 types × 4 source modes)	Varies
Entry Content	Descriptor (address + metadata)	Instructions (branch/code)	Instruction (jump)
Privilege Check	DPL in descriptor	Exception level inherent	CSR access controls

Summary: Interrupt Vector Tables

We've explored how processors map interrupt numbers to handler addresses. Let's consolidate the key takeaways:

Key Takeaways

•Vectors are indices into a table — The interrupt number serves as a direct index for constant-time handler lookup.
•Real mode IVT is simple but unprotected — 4-byte entries at address 0, no privilege checking, historical design.
•Protected mode IDT integrates with security — Rich descriptors include privilege levels, segment selectors, and per-entry stack selection.
•CPU performs extensive checks during dispatch — Bounds checking, DPL validation, privilege transitions, and automatic state saving.
•IST provides unconditional stack switching — Critical for handling faults when the current stack is corrupted.
•Linux initializes IDT during boot — Exception handlers first, then hardware IRQs, with IST for critical vectors.
•Different architectures, same concept — Whether x86 IDT, ARM vector table, or RISC-V mtvec, the goal is identical: fast mapping from interrupt number to handler.

What's Next:

Page Complete

3 / 5