Interrupts and Interrupt Handling David Ferry, Chris Gill, Brian Kocoloski CSE 422S - Operating Systems Organization Washington University in St. Louis St. Louis, MO 63130

System Architecture CPU DRAM System Bus GIC Peripheral Devices (hard drives, keyboards, adapters, etc. Bridge I/O buses GIC: Generic Interrupt Controller CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization System Architecture CPU DRAM System Bus GIC Bridge PCI bus CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization System Architecture CPU DRAM System Bus New packets come in GIC Bridge PCI bus CSE 422S – Operating Systems Organization

System Architecture CPU DRAM System Bus GIC Bridge PCI bus Hey kernel --- I need you to process these new packets CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization System Architecture CPU DRAM System Bus GIC interrupt Bridge PCI bus CSE 422S – Operating Systems Organization

System Architecture CPU DRAM System Bus GIC Bridge IO bus Write to a file on a hard drive CSE 422S – Operating Systems Organization

System Architecture CPU DRAM System Bus GIC Bridge IO bus Read from a file on a hard drive CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization Why Interrupts? Interrupts force the currently executing process to be preempted Without interrupts, a process could only be removed from the processor when it ended or voluntarily yielded Interrupts allow timely processing of hardware events Interrupts preclude the need for a (fast) CPU to poll on status of (slow) peripheral hardware Three primary interrupt use cases: Peripheral devices use interrupts to request CPU attention The timer interrupt controls the scheduling frequency of a system Processors use interrupts to communicate in multi-processor systems (e.g. for load balancing or synchronization) CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization https://www.slideshare.net/AnhDungNGUYEN3/arm-aae-system-issues CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization Interrupt Mechanisms On the ARM architecture, there are three physical types of interrupts: SWI: software interrupts (i.e. exceptions) IRQ: regular hardware interrupts FIQ: fast hardware interrupts Linux has three interrupt semantics: Software interrupts routed via SWI table Hardware interrupts routed via the Interrupt Descriptor Table (IDT) Inter-processor interrupts CSE 422S – Operating Systems Organization

Software vs. Hardware Interrupts Software interrupts we saw before: User mode initiates system calls with the SWI instruction (or on x86, the INT instruction) Illegal instructions are trapped Occurs synchronously with processor instructions Also called “exceptions” or “traps” Hardware interrupts are from devices: Indicated by an electrical signal to a processor On ARM, multiplexed by the Generic Interrupt Controller (GIC) Asynchronous with instruction stream CSE 422S – Operating Systems Organization

Inter-processor Interrupts (IPIs) Modern multi-core machines need a way for cores to communicate. Start/stop/sleep/wakeup other cores Request task migration Request remote function call (synchronization) Implemented differently from traditional interrupts, see smp_cross_call() in arch/arm/kernel/smp.c CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization System Architecture Inter-processor interrupt Used to send interrupts between CPUs; eg., for: Task migration Flushing of low-level caches CPU DRAM System Bus CPU GIC CSE 422S – Operating Systems Organization

Hardware Interrupt Interface Register new handlers with request_irq(), using three key attributes: IRQ number IRQ handler function Whether the IRQ is shared Handler functions execute in interrupt context: No process context No current, no mm_struct, etc. Disables own interrupt line (optionally all interrupts) May be interrupted by other interrupts Does not need to be re-entrant Cannot sleep CSE 422S – Operating Systems Organization

Differences Between Process and Interrupt Context Process Context Kernel is executing on behalf of a process current points to the currently executing process Can sleep (as long as it doesn’t hold a lock) Locks can be taken without disabling interrupts Interrupt Context Kernel is executing with no associated process context No user-level process No kernel thread There is no thread context on the CPU; current points to the last interrupted process Cannot sleep – how would the kernel re-schedule it without a process context? All interrupts must be disabled (on this core) before locks can be taken CSE 422S – Operating Systems Organization

Hardware Interrupt Tension Handlers must be fast Disables own interrupt line (bad for shared lines), and may disable all lines Can preempt more important work But also may have to do a lot of work Must perform potentially large amounts of work to service hardware Cannot sleep/block, so cannot call functions that can sleep/block (such as kmalloc()) Strategy: Service hardware immediately but defer as much work as possible till later. CSE 422S – Operating Systems Organization

Top Half / Bottom Half Processing Modern interrupt handlers are split into top half (fast) and bottom half (slow) components Top half: Does minimum work to service hardware Sets up future execution of bottom half Clears interrupt line Bottom half: Performs deferred processing (more about this next time) Example: Network card – top half clears card buffer while bottom half processes and routes packets CSE 422S – Operating Systems Organization

Hardware Interrupt Implementation Sequence of events on ARM: Someone registers a handler on specific IRQ line Device raises interrupt line with GIC (Generic Interrupt Controller) GIC de-multiplexes and interrupts CPU CPU jumps to interrupt descriptor table (IRQ table or FIQ table) in entry_armv.S via svn_entry and irq_handle C code starts at asm_do_irq() generic_handle_irq() (architecture independent, found in kernel/irq/irqdesc.c) Proceeds to specific handlers from there Returns after executing all handlers CSE 422S – Operating Systems Organization