Skip to main content
Engineering LibreTexts

20.3: Interrupt Processing

  • Page ID
    19990
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    When an interrupt occurs, it must be handled or processed securely, quickly, and correctly. The general idea is that when the currently executing process is interrupted it must be placed on hold, and the appropriate interrupt handling code found and executed. The specific interrupt processing required depends on the cause or purpose of the interrupt. Once the interrupt is serviced, the original process execution will eventually be resumed.

    Interrupt Service Routine (ISR)

    The code that is executed in response to an interrupt is typically called an Interrupt Service Routine or ISR. The code is sometimes referred to as interrupt handler, handler, service routine, or ISR code. For consistency, this document will use the term ISR.

    ISR code is challenging to develop due to the issues related to the concurrency and race conditions. Additionally, it is difficult to isolate problems and debug ISR code.

    Processing Steps

    The general steps involved in processing an interrupt are outlined in the following sections.

    Suspension

    Execution of the current program is suspended. As a minimum, this requires saving the rip and rFlags registers to system stack. The remaining registers are likely to be preserved (as a further step), depending on the specific interrupt. The rFlags flag register must be preserved immediately since the interrupt may have been generated asynchronously and those registers will change as successive instructions are executed. This multi-stage process ensures that the program context can be fully restored.

    Obtaining ISR Address

    The ISR addresses are stored in a table referred to as an Interrupt Descriptor Table(Note, for Windows this data structure is referred to as the Interrupt Vector Table (IVT).) (IDT). For each ISR, the IDT contains the ISR address and some additional information including task gate (priority and privilege information) for the ISR. Each entry in the IDT is a total of 8 bytes each for a total of 16 bytes per IDT entry. There is a maximum of 256 (0-255) possible entries in the IDT.

    To obtain the starting address of an ISR, the interrupt number is multiplied by 16 (since each entry is 16 bytes) which is used as offset into the IDT where the ISR address is obtained (for that interrupt).

    The start of the IDT is pointed to by a dedicated register, IDTR, which is only accessible by the OS and requires level 0 privilege to access.

    The addresses of the ISR routines are specific to the OS version and the specific hardware complement of the system. The IDT is created when the system initially boots and reflects the specific system configuration. This is critical in order for the OS to work correctly and consistently on different system hardware configurations.

    Jump to ISR

    Once the ISR address is obtained from the IDT some validation is performed. This includes ensuring the interrupt is from a legal/valid source and if a privilege level change is required and allowed. Once the verifications have been completed successfully, the address of the ISR from the IDT is placed in the rip register, thus effecting a jump to the ISR routine.

    Suspension Execute ISR

    At this point, depending on the specific ISR, a complete process context switch may be performed. A process context switch involves saving the entire set of CPU registers for the interrupted process.

    In Linux-based OS's, ISR are typically divided into two parts, referred to as the top-half and bottom-half. Other OS's refer to these as the First-Level Interrupt Handler (FLIH) and the Second-Level Interrupt Handlers (SLIH).

    The top-half or FLIH is executed immediately and is where any critical activities are performed. The activities are specific to the ISR, but might include acknowledging the interrupt, resetting hardware (if necessary), and recording any information only available at the time of interrupt. The top-half may perform some blocking of other interrupts (which needs to be minimized).

    The bottom-half is where any processing activities (if any) are performed. This helps ensure that the top-half is completed quickly and that any non-critical processing is deferred to a more convenient time. If a bottom-half exists, the top-half will create and schedule the execution of the bottom-half.

    Once the top-half completes, the OS scheduler will select a new process.

    Resumption

    When the OS is ready to resume the interrupted process, the program context is restored and an iret instruction is executed (to pop rFlags and rip registers, thus completing the restoration).


    This page titled 20.3: Interrupt Processing is shared under a CC BY-NC-SA license and was authored, remixed, and/or curated by Ed Jorgensen.