Why Interrupts Matter: Unraveling CPU Interrupt Mechanisms and the IDT

Interrupt Basics

An interrupt is an asynchronous event usually triggered by an I/O device, while an exception is a synchronous event generated when the processor detects an abnormal condition while executing an instruction.

Three Ways a CPU Gets an Interrupt Number

External devices signal the programmable interrupt controller (PIC), which maps IRQ lines to interrupt numbers and raises the INTR pin; the CPU reads the number from the controller’s port.

The CPU detects an exception during instruction execution and internally assigns a predefined interrupt number (e.g., 0x06 for an invalid instruction).

Software executes the INT n instruction, directly supplying an interrupt number (e.g., INT 0x80 for Linux system calls).

Interrupt Descriptor Table (IDT)

The IDT is simply a 256‑entry array in memory, each entry being an interrupt descriptor. In Linux‑2.6.0 the table is declared as:

struct desc_struct idt_table[256] = { {0, 0}, ... };

Each descriptor stores a segment selector and an offset, which together point to the interrupt handler’s entry address.

Descriptor Types

Task Gate – rarely used in Linux.

Interrupt Gate – disables further interrupts by clearing the IF flag.

Trap Gate – leaves the IF flag unchanged, allowing nested interrupts.

All three share the same layout; the type field merely distinguishes their behavior.

Locating the IDT

The CPU does not have a fixed address for the IDT. Operating systems load the address into the IDTR register using the LIDT instruction. The IDTR holds a 16‑bit limit (size in bytes) followed by a 32‑bit base address.

Handling an Interrupt

When the CPU receives an interrupt number n, it indexes the IDT to fetch the corresponding descriptor, extracts the segment selector and offset, and transfers control to the handler. Before jumping, the CPU performs a series of stack pushes:

If a privilege‑level change occurs, push the old SS and ESP and switch to the new stack defined in the TSS.

Push EFLAGS.

Push CS and EIP (the return address).

If the interrupt supplies an error code, push that error code.

After the handler finishes, it executes IRET (or IRETD) which pops EIP, CS, and EFLAGS (and any error code) to restore the original context.

Example: Divide‑Error Handler (Linux‑0.11)

_divide_error:
    push dword ptr _do_divide_error
no_error_code:
    xchg [esp],eax
    push ebx
    push ecx
    push edx
    push edi
    push esi
    push ebp
    push ds
    push es
    push fs
    push 0
    lea edx,[esp+44]
    push edx
    mov edx,10h
    mov ds,dx
    mov es,dx
    mov fs,dx
    call eax
    add esp,8
    pop fs
    pop es
    pop ds
    pop ebp
    pop esi
    pop edi
    pop edx
    pop ecx
    pop ebx
    pop eax
    iretd

The final iretd restores the saved registers and returns execution to the point where the exception occurred.

Key Takeaways

Interrupts (hardware‑driven) and exceptions (CPU‑driven) both ultimately deliver an interrupt number to the CPU.

The IDT maps those numbers to handler entry points; the OS populates the table during initialization.

CPU uses the IDTR register to locate the IDT, then performs privilege‑aware stack pushes before jumping to the handler.

After handling, IRET restores the saved context, allowing normal execution to resume.

Understanding these mechanisms provides a solid foundation for deeper OS topics such as network‑packet processing, soft‑interrupts, and kernel scheduling.