Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL
Help

Chapter 3. Kernel-Mode I/O Processing > Use of Interrupt Priorities by Windows ... - Pg. 40

Kernel-Mode I/O Processing 40 When a user-mode thread makes a direct request of the I/O Manager, the I/O Manager executes within the context of the requester. In turn, the I/O Manager may call a dispatch routine within a device driver. Dispatch routines of a driver therefore execute within this exception context. Interrupt Context When the hardware (or software) generates an acknowledged interrupt, whatever code is executing within the system is stopped dead in its tracks. The executing context is saved and control is promptly handed over to a service routine appropriate for the kind of interrupt that occurred. Clearly, the context of the executing code at the time of the interrupt is irrelevant and arbitrary. Kernel-mode code servicing the interrupt cannot make any assumptions about the state of the page tables. User-mode buffers must be considered unavailable in this context. Code running in interrupt context (which includes the bulk of driver routines) can make no assumptions about the current process or thread. Kernel-Mode Thread Context The final possibility is that a piece of code runs in the context of a separate kernel thread. Some drivers spawn separate threads to deal with devices that require polling or to deal with specialized timeout conditions. These kernel-mode threads are not significantly different from user-mode threads described in Win32 programming books. They execute when scheduled by the kernel's scheduler, in accordance with the assigned thread priority. Like the interrupt context, kernel-mode thread context can make no assumption about the current process or thread. The state of the page tables is largely arbitrary as seen by the thread. Chapter 14 discusses the use of kernel-mode threads. Use of Interrupt Priorities by Windows 2000 The last chapter introduced the concept of interrupt priorities as a means of arbitrating among dif- ferent 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 imple- mentation 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 (pro- nounced 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. Table 3.1. IRQL Level Usage IRQL Levels Generated By Hardware IRQL Name HIGHEST_LEVEL POWER_LEVEL Purpose Machine checks and bus errors Power-fail interrupts