CS 452/652 Winter 2022 - Lecture 12

Interrupt Handling

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 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

Interrupt Confirmation

• cause for interrupt (at device):
  • event, such as timer underflow → edge trigger
    • device will not trigger interrupt again unless previous one confirmed
  • status, such as buffer empty → level trigger
    • after completion of interrupt handler, interrupt would trigger again!
      → force status change or disable interrupt
• example: confirm timer interrupt by writing to BASE + 0x0C.

Timer Interrupt

• device automatically generates interrupt, if timer is enabled
• timer underflow: interrupt when timer reaches 0 (timer continues and/or is reloaded)
• VIC must enable/disable/configure interrupt delivery
• CPU must accept interrupts (user mode)
• generic interrupt handler

    query VIC status register for interrupt source
    choose and process interrupt
    make current task ready
    schedule next task
  

• confirm interrupt before/during/after processing

Interrupt Processing

• central interrupt processing

  query VIC status
  process interrupt
  confirm interrupt
  

  one shot, then schedule – or loop of interrupt processing?
  • one shot works, because next interrupt would be taken right before the first user instruction is being executed
  • loop should work, if VIC status is updated during kernel processing? probably...
  • are multiple/repeated interrupts pending?
    • yes/often → loop more efficient
    • no/rarely → one-shot more efficient
• one shot processing seems safe bet

AwaitEvent

• matchmaking: task ↔ event
• task(s) waiting for interrupt to occur: store one or queue? → design decision
• interrupt without waiting task: buffer one or several? or failure?
  • excessive buffering is not helpful in any producer/consumer scenario
  • multiple same interrupts without waiting task indicate performance problem!
  • use task prioritity to make sure that hardware interrupts are handled promptly
• AwaitEvent() argument and return code → design decision