The Windows 2000 Device Driver Book: A Guide for Programmers (2nd Edition)

The last chapter introduced the concept of interrupt priorities as a means of arbitrating among different I/O devices competing for CPU service. This section presents a scheme implemented by Windows 2000 that not only takes into account hardware interrupt prioritization, but extends the concept to include prioritization of execution context.

CPU Priority Levels

Since different CPU architectures have different ways of handling hardware interrupt priorities, Windows 2000 presents an idealized, abstract scheme to deal with all platforms. The actual implementation of the abstraction utilizes HAL routines that are platform-specific.

The basis for this abstract priority scheme is the interrupt request level (IRQL). The IRQL (pronounced irk-al) is a number that defines a simple priority. Code executing at a given IRQL cannot be interrupted by code at a lower or equal IRQL. Table 3.1 lists the IRQL levels used in the Windows 2000 priority scheme. Regardless of the underlying CPU or bus architectures, this is how IRQL levels appear to a driver. It is important to understand that at any given time, instructions execute at one specific IRQL value. The IRQL level is maintained as part of the execution context of a given thread, and thus, at any given time, the current IRQL value is known to the operating system.

The actual hardware interrupt levels fall between DISPATCH_LEVEL and PROFILE-LEVEL of the IRQL abstraction. These hardware interrupt levels are defined as the device IRQLs (DIRQLs).

Interrupt Processing Sequence

When an interrupt reaches the CPU, the processor compares the IRQL value of the requested interrupt with the CPU's current IRQL value. If the IRQL of the request is less than or equal to the current IRQL, the request is temporarily ignored. The request remains pending until a later time when the IRQL level drops to a lower value.

On the other hand, if the IRQL of the request is higher than the CPU's current IRQL, the processor performs the following tasks:

1. Suspends instruction execution.

2. Saves just enough state information on the stack to resume the interrupted code at a later time.

3. Raises the IRQL value of the CPU to match the IRQL of the request, thus preventing lower priority interrupts from occurring.

4. Transfers control to the appropriate interrupt service routine for the requested interrupt.

When finished, the service routine executes a special instruction that dismisses the interrupt. This instruction restores the CPU state information from the stack (which includes the previous IRQL value) and control is returned to the interrupted code.

Notice that this scheme allows higher-IRQL requests to interrupt the service routines of lower-IRQL interrupts (an interrupt of an interrupt). Because the whole mechanism is stack-based, this doesn't cause confusion. It does, however, raise synchronization issues addressed in chapter 5.

Software-Generated Interrupts

The lower entries in the IRQL list of Table 3.1 are tagged as being software-generated. Some interrupt processing is initiated by kernel-mode code by the execution of a privileged instruction. Windows 2000 uses these software interrupts to extend the interrupt prioritization scheme to include thread scheduling. It can be used to synchronize activity among competing threads by arbitrarily raising the IRQL of one thread to prevent interruption by the others. The next section describes the use of software interrupts and IRQL levels to schedule medium-priority driver tasks.