Interrupt Handling

Exception and Interrupt Processing in AOS

Overview

Interrupts and exceptions are critical for OS functionality. The Interrupt Descriptor Table (IDT) maps 256 possible interrupt vectors to handler functions, allowing the CPU to respond to hardware events and software exceptions.

What is the IDT?

The IDT is similar to the GDT but for interrupts:

256 possible entries (0-255)
Entry 0-31: CPU exceptions (division by zero, page fault, etc.)
Entry 32-47: Hardware interrupts (timer, keyboard, disk)
Entry 48-255: Software interrupts and reserved

CPU Exception Vectors (0-31)

#	Name	Cause	Action
0	Divide Error	Division by zero	Fault
13	General Protection	Permission violation	Fault
14	Page Fault	Page not in memory	Fault
32	Timer	Timer interrupt	Interrupt
33	Keyboard	Keyboard input	Interrupt

Interrupt Flow

1. Hardware Event or CPU Exception ↓ 2. CPU looks up IDT entry (based on vector number) ↓ 3. CPU pushes registers and return address ↓ 4. CPU jumps to handler address from IDT ↓ 5. Interrupt stub handler (assembly) ↓ 6. C interrupt dispatcher (isr_handler) ↓ 7. Specific handler (page_fault_handler, etc.) ↓ 8. Handler returns ↓ 9. Assembly restores registers ↓ 10. IRETQ returns to original code

Enabling/Disabling Interrupts

// Enable interrupts (set IF flag in RFLAGS)
static inline void enable_interrupts(void) {
    asm volatile("sti");
}

// Disable interrupts (clear IF flag)
static inline void disable_interrupts(void) {
    asm volatile("cli");
}

Key Takeaways

✓ IDT maps 256 interrupt vectors to handlers
✓ First 32 entries for CPU exceptions
✓ Entries 32-47 for hardware interrupts
✓ LIDT loads IDT into CPU
✓ Assembly stubs coordinate with C handlers
✓ Interrupt frame contains register state
✓ FLAGS register controls masking