What is an Interrupt Vector Table?
Learn what an interrupt vector table is — direct handler dispatch, the x86 IDT, and fallback faults — with OS interview questions answered.
Expected Interview Answer
An interrupt vector table (IVT) is an array of handler addresses indexed by interrupt or exception number, used by the CPU to jump directly to the correct handler routine the instant an interrupt or trap occurs, without any software lookup.
Each entry in the table corresponds to a specific interrupt number — for example, entry 0 might be the divide-by-zero handler, entry 0x20 a timer interrupt, and entry 0x80 the system-call entry point — and the CPU hardware reads the interrupt number presented by the interrupting device or instruction, multiplies it by the entry size, and jumps straight to the address stored at that offset. On architectures like x86, this table is called the Interrupt Descriptor Table (IDT) and can live anywhere in memory pointed to by a dedicated register (IDTR); the OS populates it once during boot, registering a handler function pointer for every interrupt number it cares about. Because the lookup is a direct array index rather than a search, dispatch is extremely fast and has constant, predictable latency, which matters for real-time responsiveness. If an interrupt number arrives that has no properly initialized entry, or if a fault occurs while already handling another fault, the CPU raises a special fallback such as a double fault or general protection fault to avoid running through garbage memory.
- Explains constant-time O(1) interrupt dispatch versus a lookup search
- Clarifies why the OS must initialize every vector during boot
- Connects to real hardware structures like x86 IDT and the IDTR register
- Explains double faults as the fallback for missing/corrupt vector entries
AI Mentor Explanation
An interrupt vector table is like a numbered pigeonhole board at the pavilion where each incident type has a pre-assigned slot: slot 1 always holds the physio's phone number, slot 2 the groundskeeper's, slot 3 the umpire's. When an incident number is announced over the tannoy, staff go straight to that exact pigeonhole rather than searching a directory, giving instant, predictable response every time. If a slot is ever left empty, the club has a fallback emergency contact posted at the entrance, just like a CPU falling back to a double fault handler.
Step-by-Step Explanation
Step 1
Table initialization
During boot, the OS populates every entry it cares about with a handler function pointer, indexed by interrupt/exception number.
Step 2
Register the base
The CPU is told where the table lives, e.g. via the IDTR register on x86 pointing to the Interrupt Descriptor Table.
Step 3
Interrupt occurs
The CPU or a device presents an interrupt number; hardware multiplies it by entry size and indexes directly into the table.
Step 4
Direct jump
Control transfers straight to the address stored at that index — O(1), no software search — or a fallback fault fires if the entry is missing.
What Interviewer Expects
- Clear definition: array of handler addresses indexed by interrupt number
- Understanding that dispatch is O(1) direct indexing, not a search
- Knowledge of a real example, e.g. x86 IDT and the IDTR register
- Awareness of the double-fault/fallback path for missing entries
Common Mistakes
- Thinking the OS searches a list to find the right handler at runtime
- Confusing the interrupt vector table with the page table
- Not knowing the OS must initialize the table at boot before interrupts are enabled
- Forgetting what happens when an interrupt number has no valid handler entry
Best Answer (HR Friendly)
“An interrupt vector table is essentially a lookup array the operating system fills in ahead of time, one slot per type of interrupt, holding the address of the code that should run for that interrupt. When something happens, the hardware uses the interrupt’s number to jump straight to the right slot instantly, instead of searching for the right code, which keeps response times fast and predictable.”
Code Example
#define NUM_VECTORS 256
typedef void (*isr_handler_t)(void);
isr_handler_t interrupt_vector_table[NUM_VECTORS];
void divide_by_zero_handler(void) { /* handle CPU exception 0 */ }
void timer_handler(void) { /* handle IRQ0 / vector 0x20 */ }
void syscall_entry(void) { /* handle software trap 0x80 */ }
void default_fault_handler(void) { /* fallback: unmapped vector */ }
void init_vector_table(void) {
for (int i = 0; i < NUM_VECTORS; i++)
interrupt_vector_table[i] = default_fault_handler;
interrupt_vector_table[0x00] = divide_by_zero_handler;
interrupt_vector_table[0x20] = timer_handler;
interrupt_vector_table[0x80] = syscall_entry;
load_idtr(interrupt_vector_table); /* tell CPU where table lives */
}
/* Hardware dispatch: O(1) direct index, no search */
void cpu_dispatch(int vector_num) {
interrupt_vector_table[vector_num]();
}Follow-up Questions
- What is the x86 Interrupt Descriptor Table (IDT) and what does the IDTR register hold?
- What happens if an interrupt fires with no handler registered for its vector number?
- What is a double fault, and how does it relate to the vector table?
- How does the vector table differ from a page table or a system call table?
MCQ Practice
1. What does an interrupt vector table primarily store?
The vector table is an array where each index (interrupt number) holds the address of the corresponding handler routine.
2. Why is dispatch via the interrupt vector table fast?
Because the table is indexed directly by interrupt number, the CPU jumps to the handler in constant time with no lookup search.
3. On x86, what CPU register points to the Interrupt Descriptor Table?
The IDTR register holds the base address and size of the Interrupt Descriptor Table on x86 architectures.
Flash Cards
What is an interrupt vector table? — An array of handler addresses indexed by interrupt/exception number for direct dispatch.
What is the x86 name for this structure? — The Interrupt Descriptor Table (IDT), pointed to by the IDTR register.
Why is vector table dispatch fast? — It is a direct O(1) array index, not a runtime search.
What happens on an unmapped vector? — A fallback fault, such as a double fault, is raised instead of jumping to garbage.