CS 452/652 Spring 2022 - Lecture 9
May 31, 2022
- 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
- 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 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
- 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