인터럽트 설명자 테이블(IDT)

Imagine the CPU gets a signal that something important happened – like you pressing a key or a program crashing. How does it know what code to run to handle that event? That's where the Interrupt Descriptor Table (IDT) comes in!

It's like a special phone book for your CPU. Each entry in this 'phone book' tells the CPU exactly where to go to find the right code (an 'interrupt handler') for a specific event.

Without the IDT, the CPU wouldn't know how to react to different events. It provides a structured way for the processor to dispatch control to the appropriate routine when an interrupt or exception occurs.

This allows the operating system to respond to hardware signals, software requests, and errors in a controlled and organized manner, ensuring system stability.

Each entry in the IDT isn't just a simple memory address. It's called a Gate Descriptor. Think of a gate as a secure doorway.

When the CPU 'opens' a gate, it gets all the information it needs to safely jump to the interrupt handler. The most common types for interrupts and exceptions are Interrupt Gates and Trap Gates.

A Gate Descriptor primarily tells the CPU where the interrupt handler's code is located. It does this using two main parts:

• Segment Selector: Points to a code segment in memory.
• Offset: The exact starting address (or offset) within that code segment.

Together, these form the full memory address of the handler function.

Besides location, gates also specify important control information:

• Descriptor Privilege Level (DPL): This is a security feature. It defines the minimum privilege level required to access this gate. For example, a user-level program (low privilege) might not be allowed to trigger a critical kernel interrupt (high privilege).
• Type Field: Specifies if it's an Interrupt Gate, Trap Gate, or Task Gate. This is crucial for how the CPU behaves when the gate is entered.

The key difference between an Interrupt Gate and a Trap Gate lies in how they handle CPU interrupts:

• Interrupt Gate: Automatically clears the Interrupt Flag (IF) in the CPU's EFLAGS register when entered. This disables further hardware interrupts, preventing new interrupts from disturbing the current handler.
• Trap Gate: Does NOT clear the Interrupt Flag. This means other interrupts can still occur while the current handler is running. Usually used for exceptions where you might want further interrupts to be handled.

When an interrupt or exception occurs, the CPU performs these steps:

1. It gets an 'interrupt vector' (a number) identifying the event.
2. It uses this vector as an index into the IDT to find the corresponding Gate Descriptor.
3. It checks the DPL to ensure the current privilege level is sufficient.
4. It loads the segment selector and offset from the gate to find the handler's address.
5. It pushes the current EFLAGS, CS, and EIP (return address) onto the stack.
6. It jumps to the interrupt handler's code specified by the gate.

The CPU needs to know where the IDT is located in memory. This is done using the IDTR (Interrupt Descriptor Table Register).

The LIDT (Load Interrupt Descriptor Table) instruction is used to load the base address and size of the IDT into the IDTR. This is a privileged instruction, meaning only the operating system kernel can execute it.

The operating system is responsible for setting up and managing the IDT:

• It initializes the IDT during system boot.
• It populates the IDT with appropriate Gate Descriptors for all expected hardware interrupts, software interrupts, and exceptions.
• It ensures that each gate points to the correct handler routine, often within the kernel itself.

This careful setup is vital for system stability and security.

In this lesson, we explored the Interrupt Descriptor Table (IDT), the CPU's essential 'phone book' for handling events.

We learned that the IDT consists of Gate Descriptors, which specify the handler's location, privilege level, and type. We also distinguished between Interrupt Gates (which disable further interrupts) and Trap Gates (which do not).

The operating system plays a crucial role in setting up and managing the IDT to ensure a stable and responsive system. Understanding the IDT is key to comprehending how the x86 architecture manages low-level events.