Questions: Interrupt Vector Tables and Dispatch

Question 1

When interrupt number 14 (page fault) fires on an x86 processor, how does the CPU determine which handler to execute?

• A. The CPU scans kernel code for a function named 'page_fault_handler'
• B. The CPU raises a special page-fault signal and waits for the OS to respond
• C. The CPU indexes into the interrupt descriptor table at position 14, reads the stored handler address, and jumps to it
• D. The CPU checks the interrupt type register and executes a switch statement in microcode

Answer: (C)

The interrupt vector table (IDT on x86) is an array where each position stores the address of the corresponding handler. Interrupt 14 → IDT[14] → address of page fault handler → jump. This is a single indexed memory access, not a search. The entire mechanism is designed for speed — interrupts can happen millions of times per second and cannot afford conditional logic. Option A describes an impossible runtime search; Option D confuses hardware dispatch with software logic.

Question 2

An interrupt fires while a user process is executing on x86. What does the CPU automatically do before jumping to the kernel handler?

• A. The CPU does nothing automatically — the handler is responsible for saving all state before using any registers
• B. The CPU saves the instruction pointer and flags register onto the stack, and switches to the kernel stack if crossing privilege levels
• C. The CPU pauses all other processes and sends an acknowledgment signal to the interrupting device
• D. The CPU copies the entire process address space into a kernel buffer for safe handling

Answer: (B)

x86 automatically saves the instruction pointer (so execution can resume) and the flags register onto the stack when an interrupt fires. If the interrupt occurred during user-mode execution, the CPU also switches to the kernel stack and saves the user stack pointer and code segment — enforcing the privilege boundary. This automatic save enables the handler to run in kernel context and then execute 'iret' to restore the saved state and resume the interrupted code exactly where it left off. Option A would make reliable interrupt handling impossible.

Question 3

When a hardware interrupt fires, the CPU searches through kernel code to find the correct handler function based on the type of interrupt.

• T. True
• F. False

Answer: False

The interrupt vector table exists precisely to avoid any searching. Dispatch is a single O(1) array lookup: interrupt number → table index → handler address → jump. This is the fundamental design insight — speed is critical because interrupts are frequent and latency matters. A search through kernel code would be far too slow and error-prone. The OS pre-populates the table at boot so that all dispatching at runtime is just one indexed memory read.

Question 4

The operating system populates the interrupt vector table during boot, before any user processes run.

• T. True
• F. False

Answer: True

Boot-time initialization of the interrupt vector table is essential — if the table isn't set up before devices start firing interrupts, the CPU would have nowhere valid to jump. During early kernel initialization, the OS writes handler addresses into each IDT slot, then loads the table's base address into the IDTR register (on x86) so the CPU knows where the table lives. Hardware device drivers also register their handlers as devices are initialized. All of this happens before the kernel starts scheduling user processes.

Question 5

Why does the interrupt dispatch mechanism use an indexed array (the interrupt vector table) rather than a set of if-else conditions in the kernel, and what makes this design critical for system performance?

Model answer: An indexed array makes dispatch O(1): given interrupt number k, the CPU reads one memory location (table[k]) to get the handler address — no comparison, no branching. If-else chains would require O(n) comparisons in the worst case, and n can be 256 on x86. More importantly, interrupt dispatch must complete in a handful of cycles — timer interrupts fire thousands of times per second, disk and network interrupts fire continuously under load. Any latency in dispatch directly impacts I/O throughput and system responsiveness. The array design offloads all flexibility to boot-time setup while keeping runtime dispatch instant.

The interrupt vector table is a textbook example of trading setup cost for runtime speed. The OS pays a one-time cost at boot to populate the table; thereafter, every dispatch is a single indexed read. This pattern — precomputed lookup tables for performance-critical paths — appears throughout systems software. The alternative (conditional dispatch) would be not just slow but fragile, as devices are added and removed dynamically.