IRQL (reproduced from Windows Kernel Scenario Analysis)

Related to this, Windows defines many "IRQ levels" for the CPU running status, that is, IRQL. At any time, the CPU always runs at a certain level, which indicates what can be done and what cannot be done. The following are definitions of these levels:

# Define passive_level 0

# Define low_level 0

# Define apc_level 1

# Define dispatch_level 2

# Define profile_level 27

# Define clock1_level 28

# Define clock2_level 28

# Define ipi_level 29

# Define power_level 30

# Define high_level 31

The basic intention is that if the CPU and thus a thread are already at a certain level, their operations will not be affected by operations at the same level or lower level.

Passive_level is the lowest level.
But it corresponds to a higher level in the system structure. When the CPU runs in the user space or enters the kernel but only runs in the management layer, its running level is
Passive_level. It is slightly higher than apc_level, which is the runtime level when the (in the kernel) is the execution of the APC function (see Chapter "process and thread" in this book ).
The APC request is equivalentProgram(Software) interruption. Note that IRQL does not support hardware in the x86 system structure (the CPU does not have such a register) but is just a variable.
Unlike CPU, which can only enter the system state through special commands or interruptions/exceptions, IRQL is set freely by the CPU. IRQL is increased whenever the CPU enters a lower-level and more-core level, reverse
Then, IRQL is reduced. However, it indicates that IRQL variables in the kernel cannot be changed when running in the user space.

The higher level is dispatch_level, which is roughly equivalent to the core layer where the CPU runs in the Windows Kernel, that is, the "kernel" layer. Thread switching can only happen when the CPU line drops from dispatch_level.

IRQL Level 3 and above are used for hardware interruption. Obviously, the designer intends to adopt the interrupt priority, that is, the interrupt source with a higher priority can interrupt services with a lower priority. However, the x86 system structure does not support the interruption priority. Therefore, this is actually the legacy of VMS, because the VAX and PDP system structures support the interruption priority.

Back to the page for issues, as long as the cpu irql level
It must not be higher than the level of apc_level.CodeSwitch is allowed, but it is not allowed from dispatch_level. Obviously, if you make a mistake at this point, the consequence is very strict.
. Therefore, in the Code of the management layer, a macro operation paged_code () should be put at the beginning of almost every function, indicating that the author's intention is to let the page occupied by this function be swapped out.
The macro operation is defined as follows:

# Ifdef dbg

# Define paged_code (){"

If (kegetcurrentirql ()> apc_level ){"

Kdprint ("ntddk: pageable code called at IRQL> apc_level (% d)" N ",

Kegetcurrentirql ()));"

Assert (false );"

}"

}

# Else

# Define paged_code ()

# Endif

In debug mode, this macro operation checks the current CPU running level. If it finds that it is higher than apc_level, this function may be called at dispatch_level or a higher level, therefore, it should not be switched out, so a warning is issued. In the official version, this macro operation is defined as null.

Of course, macro operations are referenced only in the program.
Paged_code () does not change the page where a function is located. What actually changes is the Compilation instruction "# pragma
Alloc_text ()". For example, in ntqueryobject (), the first line is paged_code (). Correspondingly, the source file where the function is located has such
Row:

# Pragma alloc_text (page, ntqueryobject)

This line of compilation indicates that the compilation tool places the executable code generated for this function in the SWAp interval.