Interrupts
- Interrupts and exceptions (x86)
- Interrupts and exceptions (Linux)
- Deferrable work
- Timers
Interrupts
- synchronous, generated by executing an instruction
- asynchronous, generated by an external event
- maskable
- can be ignored
- signalled via INT pin
- non-maskable
- cannot be ignored
- signalled via NMI pin
Exceptions
- processor detected
- faults
- traps
- aborts
- programmed
- int n
Quiz: interrupt terminology
For each of the following term on the left select all the terms from right that best describe them.
|
|
Programmable Interrupt Controller
Interrupt controllers in SMP systems
Enabling/disabling the interrupts
- at the device level
- by programming the device control registers
- at the PIC level
- PIC can be programmed to disable a given IRQ line
- at the CPU level; for example, on x86 one can use the following instructions:
- cli (CLear Interrupt flag)
- sti (SeT Interrupt flag)
Interrupt priorities
Quiz: hardware concepts
Which of the following statements are true?
- The CPU can start processing a new interrupt before the current one is finished
- Interrupts can be disabled at the device level
- Lower priority interrupts can not preempt handlers for higher priority interrupts
- Interrupts can be disabled at the interrupt controller level
- On SMP systems the same interrupt can be routed to different CPUs
- Interrupts can be disabled at the CPU level
Interrupt Descriptor Table
- it is used as a jump table by the CPU when a given vector is triggered
- it is an array of 256 x 8 bytes entries
- may reside anywhere in physical memory
- processor locates IDT by the means of IDTR
Linux IRQ vector layout
Interrupt descriptor table entry (gate)
Interrupt handler address
Interrupt handler stack
Handling an interrupt request
CPU checks the current privilege level
if need to change privilege level
- change stack with the one associated with new privilege
- save old stack information on the new stack
save EFLAGS, CS, EIP on stack
save error code on stack in case of an abort
execute the kernel interrupt handler
Returning from an interrupt
- pop the eror code (in case of an abort)
- call IRET
- pops values from the stack and restore the following register: CS, EIP, EFLAGS
- if privilege level changed returns to the old stack and old privilege level
Inspecting the x86 interrupt handling
Quiz: x86 interrupt handling
The following gdb commands are used to determine the handler for the int80 based system call exception. Select and arrange the commands or output of the commands in the correct order.
(void *) 0xc15de780 <entry_SYSENTER_32>
set $idtr_addr=($idtr_entry>>48<<16)|($idtr_entry&0xffff)
print (void*)$idtr_addr
set $idtr = 0xff800000
(void *) 0xc15de874 <entry_INT80_32>
set $idtr = 0xff801000
set $idtr_entry = *(uint64_t*)($idtr + 8 * 128)
monitor info registers
Interrupt handling in Linux
IRQ and exception nesting in Linux
- an exception (e.g. page fault, system call) can not preempt an interrupt; if that occurs it is considered a bug
- an interrupt can preempt an exception
- an interrupt can not preempt another interrupt (it used to be possible)
Interrupt/Exception nesting
Interrupt context
- it runs as a result of an IRQ (not of an exception)
- there is no well defined process context associated
- not allowed to trigger a context switch (no sleep, schedule, or user memory access)
Deferrable actions
- Schedule callback functions to run a later time
- Interrupt context deferrable actions
- Process context deferrable actions
- APIs for initialization, scheduling and masking
Soft IRQs
Soft IRQ APIs:
- initialize:
open_softirq()- activation:
raise_softirq()- masking:
local_bh_disable(),local_bh_enable()Once activated, the callback function
do_softirq()runs either:
- after an interrupt handler or
- from the ksoftirqd kernel thread
ksoftirqd
- minimum priority kernel thread
- runs softirqs after certain limits are reached
- tries to achieve good latency and avoid process starvation
Types of soft IRQs
/* PLEASE, avoid to allocate new softirqs, if you need not _really_ high
frequency threaded job scheduling. For almost all the purposes
tasklets are more than enough. F.e. all serial device BHs et
al. should be converted to tasklets, not to softirqs.
*/
enum
{
HI_SOFTIRQ=0,
TIMER_SOFTIRQ,
NET_TX_SOFTIRQ,
NET_RX_SOFTIRQ,
BLOCK_SOFTIRQ,
IRQ_POLL_SOFTIRQ,
TASKLET_SOFTIRQ,
SCHED_SOFTIRQ,
HRTIMER_SOFTIRQ,
RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */
NR_SOFTIRQS
};
Packet flood example
Tasklets
Tasklets are a dynamic type (not limited to a fixed number) of deferred work running in interrupt context.
Tasklets API:
- initialization:
tasklet_init()- activation:
tasklet_schedule()- masking:
tasklet_disable(),tasklet_enable()
Tasklets are implemented on top of two dedicated softirqs:
TASKLET_SOFITIRQ and HI_SOFTIRQ
Tasklets are also serialized, i.e. the same tasklet can only execute on one processor.
Workqueues
Workqueues are a type of deferred work that runs in process context.
They are implemented on top of kernel threads.
Workqueues API:
- init:
INIT_WORK- activation:
schedule_work()
Timers
Timers are implemented on top of the
TIMER_SOFTIRQTimer API:
- initialization:
setup_timer()- activation:
mod_timer()
Deferrable actions summary
- softIRQ
- runs in interrupt context
- statically allocated
- same handler may run in parallel on multiple cores
- tasklet
- runs in interrupt context
- can be dynamically allocated
- same handler runs are serialized
- workqueues
- run in process context
Quiz: Linux interrupt handling
Which of the following phases of interrupt handling runs with interrupts disabled at the CPU level?
- Critical
- Immediate
- Deferred