Interrupt Handlers
This is a CPU feature. CPU executes whatever code is available at the instruction pointer. It can't simply directly handover or call the kernel code like a function call.
It will use its hardware circuits to copy existing CPU state to a stack and also update the interrupt handler's memory location to the instruction pointer register itself.
Interrupt Vector Table
This table maps each interrupt id to the address of its handler.
It's called a vector table because this table shows the direction where to go.
Hardware Interrupts
For hardware interrupts, the table holds the list of device drivers. Interrupt handlers are part of the device driver.
- During boot, the BIOS reads each device's config needs. It assigns an IRQ ID to each device and stores it in the config space.
- During kernel init, each device driver reads the IRQ ID from its device's config space. It then updates the IVT with its handler address for that IRQ ID.
For hardware interrupts, the CPU polls the interrupt flag at set intervals.
This is why interrupts are always asynchronous.
Software Interrupts
This interrupt comes from userspace apps to the kernel. It asks for a service from the operating system.
During boot, the kernel registers itself as one of the handlers in the IVT table.
These software interrupts are called system calls.
In case of Linux, the ID of the software interrupt handler in the IVT is always 128 (0x80)
IRET is the instruction that switches the CPU mode back to user mode.
Inter Processor Interrupts
This interrupt is created by the processor hardware itself for other processors in the same computer.