CS 452/652 Spring 2022 - Lecture 9

Interrupts

Basics

• motivation: avoid overhead from continuous polling
• hardware delivers asynchronous notifications
  • kernel potentially notifies task(s)
• interrupt handling also presents overheads
  • direct: pipeline flush, handler execution
  • indirect: cache disturbance (CPU, TLB, branch predictors)
• high-rate of interrupts? use hybrid approach:
  • poll device and deliver event
  • only enable interrupt, if poll (or several polls) unsuccessful
  • disable interrupt after it is triggered
  • real-world example: Linux NAPI
• not strictly necessary for CS 452 kernel

Context Switch

• return-to-task: task → IRQ → task
  • simple: use IRQ stack for task's execution context
  • example: record clock tick for later processing
  • example: record event on one core for later processing on another core
  • but: not used in CS 452 kernel
• preemption: task → IRQ → kernel → (other) task
  • dedicated IRQ/kernel stack per user task?
    • hardware-supported on Intel/AMD x86-64 architecture
    • could be emulated in software on ARM 920T?
    • mode switch user/kernel: callee-owned registers on thread's kernel stack
    • thread switch in kernel: caller-owned registers on thread's kernel stack
  • single kernel stack
    • default mode for ARM 920T - IRQ handler executes on single IRQ stack
    • all state is critical ⇒ (at least temporarily) push some info on IRQ stack
    • obtain and save user execution state
    • transition to SVC stack for kernel execution
• here: always preempt, i.e., append current task to ready-queue and re-schedule!

Interrupt Hardware

• interrupt propagation: Device → Interrupt Controller → CPU
  • interrupt raised by device
  • interrupt routed by controller
  • interrupt taken and processed by CPU
• EP 9302 has two vectored interrupt controllers (VIC) of type PL190
• see Chapter 6 in EP93xx User Guide, or see PL190 manual
  • Section 6.1.2 lists 64 numbered interrupt sources, among them:
  • 3x timer underflow, several UART interrupts
• two routing modes in PL190 VIC
  • vectored interrupt processing
    • VIC determines interrupt service routine (ISR)
    • VIC determines priority
    • faster, but VIC setup/programming more complex
  • central interrupt processing
    • single entry routine at 0x18/0x38, similar to SWI setup
    • software queries VIC status register to determine interrupt sources
    • software decides priority and invokes actual interrupt handler
    • recommendation: perform query and handling from kernel C/C++ code;
      keep context-switch assembly as simple as possible!
    • sufficient for CS 452 kernel; VIC setup simpler
• VIC default/startup configuration:
  • all IRQs disabled
  • all FIQs disabled
  • (all) vectored interrupts disabled

Interrupt Handler

• handler starts in IRQ mode, must eventually switch to SVC mode
• IRQ stack designated by IRQ mode's banked sp register → valid memory address?
• one or multiple kernel entry routines for SWI vs. IRQ possible
• storage/layout of user state?
  • same for both SWI and IRQ entry
  • different and keep track of entry type
• enter/leave routine?
  • same: can dynamically detect IRQ handling via cpsr
  • different: can use assembler macros to avoid source code duplication
• See example in demo09. Take a look at the source assembler version or use objdump -d to look at the binary code.
  • handler.S - using assembler macros (similar to C preprocessor) to code uniform routine for swi- or irq-based kernel entr

Case Study: Working with Imperfect Information

• interrupt processing with respect to the ARM 920T pipeline?
• difficult to find direct information in ARM manuals
  • we know: interrupts logically arrive in between any two instructions
  • online search: ARM 920T has 5 pipeline stages: fetch, decode, execute, memory (read/write), register write-back
  • ARM documentation: return from interrupt handler should branch to lr-4.
• conclusion: when interrupt is taken at clock tick,
  • instructions beyond 'fetch' stage are finished,
  • the just fetched instruction is discarded, but
  • pc points to next instruction, therefore
  • the discarded instruction at pc-4 needs to be re-issued after return from IRQ handler.
• this also explains why pc-relative interrupt vector instructions (see Lecture 4) operate at pc+8.
  • during 'execute' stage, pc points to two instructions later