CS 452/652 Winter 2022 - Lecture 11
January 31, 2022
prev next
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
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
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, write
- 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 with interrupt vector instructions (see Lecture 6) operate at pc+8.
- during 'execute' stage, pc points to two instructions later
Coding
See example in demo11. 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 entry.