How IRQL works under the hood

NTDEV
1

Hi,

I?m starting to learn Windows Internals and I have a question about the IRQL concept under the hood.
I did some statements below about how I think that works under the hood.

  1. IRQL is totally implemented in software by Windows. It doesn?t use any resource from the IA-32 architecture.

  2. For every IA-32 processor we have an IDT table that maps an interrupt/exception id to an ISR. When an interrupt/exception occurs the processor calls the ISR for that interrupt/exception and this ISR raises the IRQL (KeRaiseIrql), does its job and then lowers the IRQL (KeLowerIrql) again.

  3. If during the execution of an ISR another interrupt occurs with a lower IRQL than the current level than Windows add this as DPC? *I think that this statement is totally wrong*

Please let me know if I?m going in the right direction.

Thanks in advance,

Regards,

-George

2

> 1. IRQL is totally implemented in software by Windows. It doesn?t use any resource from

the IA-32 architecture.

Only on PIC HAL. On APIC one it relies upon local APIC’s Task Priority Register…

  1. For every IA-32 processor we have an IDT table that maps an interrupt/exception id to an ISR.

Correct…

When an interrupt/exception occurs the processor calls the ISR for that interrupt/exception
and this ISR raises the IRQL (KeRaiseIrql), does its job and then lowers the IRQL (KeLowerIrql) again.

Basically, yes. - there are some “specifics”, but the general idea is correct…

  1. If during the execution of an ISR another interrupt occurs with a lower IRQL than the
    current level than Windows add this as DPC?

No, local APIC keeps it pending until ISR lowers IRQL and issues EOI. At this point lower-priority interrupt
will fire. DPCs are executed in context of yet another software interrupt with even a lower priority…

Anton Bassov

3


3. If during the execution of an ISR another interrupt occurs with a lower
IRQL than the current level than Windows add this as DPC? I think that this
statement is totally wrong

Your are correct. This statement is totally wrong :slight_smile:

When the processor IRQL has been raised by an ISR to the ‘device IRQL’ of
the interrupting device(s), all interrupts (on that processor) for device(s)
with lower ‘device’ IRQL’ will be masked *off* by the hardware. As such,
the interrupt will for all intents and purposes not occur until the
processor IRQL is lowered below the interrupting device’s ‘device IRQL’. At
that point, the interrupt will occur.

A lower IRQL interrupt will not cause an interrupt on the target processor
when the target processor is at or above that same IRQL.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of George Luiz
Bittencourt
Sent: Monday, October 13, 2008 5:28 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How IRQL works under the hood

Hi,

I?m starting to learn Windows Internals and I have a question about the IRQL
concept under the hood.
I did some statements below about how I think that works under the hood.

  1. IRQL is totally implemented in software by Windows. It doesn?t use any
    resource from the IA-32 architecture.

  2. For every IA-32 processor we have an IDT table that maps an
    interrupt/exception id to an ISR. When an interrupt/exception occurs the
    processor calls the ISR for that interrupt/exception and this ISR raises the
    IRQL (KeRaiseIrql), does its job and then lowers the IRQL (KeLowerIrql)
    again.

  3. If during the execution of an ISR another interrupt occurs with a lower
    IRQL than the current level than Windows add this as DPC? *I think that this
    statement is totally wrong*

Please let me know if I?m going in the right direction.

Thanks in advance,

Regards,

-George

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

> At that point, the interrupt will occur.

Please note that the current_ priority=max(TPR, PPR) . Therefore, interrupt may fire only when both conditions below are met:

  1. The value in TPR is below vector/16. This will happen when your lower IRQL
  2. The value in PPR is below vector/16. This will happen when your issue EOI.

Windows issue EOI only after ISR returns. Therefore, even if ISR lowers IRQL it is still not going to get interrupted by lower-priority interrupt…

Anton Bassov

5

Thanks Anton excellent. If I may be so bold as to add. When speaking of the HAL PIC we mean of course the 8295A Interrupt Controller, which was the used in the “older” PCs prior to the APIC general use. Indeed the IRQL was maintained in software and APC and DPC were indeed software interrupts checked at “important times” in NT as to when to be called. See the reference: http://www.joseflores.com/jf/docs/ExploringIrql.html
The APIC and IOAPIC allows this to be done in hardware and APCs and DPC interrupts are done in hardware. See the reference: http://www.microsoft.com/whdc/archive/io-apic.mspx. Note the reference about the Dec Alpha and APC and DPC interrupting being done in hardware. Interesting for historical reasons maybe. For even more technical info you have either the Intel specs or the Mindshare book on the Pentium. Please note the following exceoption to the rule of IRQL prevents interrupts less than or equal too it level, see page 94. Microsoft Windows Internals Fouth Edition. by Soloman and Russinovich Note: An exeception to the rule that raising the IRQ blocks interrupts of that level and lower relates to APC_LEVEL interrupts. If a thread raises the IRQL to APC_LEVEL and then is recheduled because of a DISPATCH_LEVEL interrupt, the system might deliver and APC_LEVEL interrupt to the newly scheduled thread. Thus, APC_LEVEL can be considered a thread-local rather than processor-wde IRQL. May I add that the APC queues are indeed in the KTHREAD structure, hence thread specific while DPCs are processor relative. Again truely the Best of Luck and then some…

6

Starting with Vista, IRQL management is always done partially in software (using the lazy IRQL technique… similar, though not the same implementation as, to the way it was done on the old PIC HAL).

Peter
OSR

7

> Starting with Vista, IRQL management is always done partially in software (using the lazy

IRQL technique…

With such approach it is possible to make ISRs and DPCs scheduleable - just block interrupt source in your stub, and, at this point, you will be able to process ISR whenever you like. If you want to go the full way, you can even convert them to full-fledged interrupt threads with their own stacks and, hence, the ability to make blocking calls. This will eliminate the very construct of a spinlock - the only one who would use it is dispatcher itself. The drawback is that it will come at some performance penalty and introduce the additional complexity to the kernel, particularly because of having to find a solution that eliminates priority inversion problem…

Anton Bassov

8

Well, that’s true for 32-bit OSes, but not for 64-bit ones. You might
notice that the DDK headers inline KeRaiseIrql and KeLowerIrql for 64-bit
OSes, and that it’s just a move to/from CR8.

The point, though, is that there is an OS contract around these functions
that none of the implementations violate. Dwelling on the specific
implementations makes you think that you know something that may not be true
in the future. (I know that I’ll never convince Anton of this, so save your
fingers and don’t bother.)

So statements like “the PIC HAL does lazy IRQL,” when two of several PIC
HALs have in some versions of NT done lazy IRQL, don’t really matter much.
Focussing on the interface contract is more useful.

And the interface contract on IRQL is the following:

If you’re at or above a particular IRQL, interrupts at that IRQL will not be
delivered. Your ISR will not run. Your code holding locks will not be
pre-empted.

–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…
>


>
> Starting with Vista, IRQL management is always done partially in software
> (using the lazy IRQL technique… similar, though not the same
> implementation as, to the way it was done on the old PIC HAL).
>
> Peter
> OSR
>
>
>

9

> Dwelling on the specific implementations makes you think that you know something that may

not be true in the future. (I know that I’ll never convince Anton of this, so save your fingers
and don’t bother.)

Actually, exactly the opposite - the whole point of my post is that the concept of IRQL has different implementations on different HALs…

BTW, why don’t you want just to introduce interrupt threads with dedicated stacks??? Interrupt handler stubs will mask of a given interrupt the way it is appropriate for given HAL, and give a scheduler a chance to decide what has to be processed first. The very first thing that gets into ones head is the additional overhead, but, according to Solaris papers, in actuality, it somehow resulted in overall performance improvement when interrupt threads got introduced to Solaris…

Anton Bassov

10

I honestly don’t know what Solaris did. If I were still working on these
things, I might take a look.

I suspect that the change to the driver contract would be too much to bear.

–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…
>> Dwelling on the specific implementations makes you think that you know
>> something that may
>> not be true in the future. (I know that I’ll never convince Anton of
>> this, so save your fingers
>> and don’t bother.)
>
> Actually, exactly the opposite - the whole point of my post is that the
> concept of IRQL has different implementations on different HALs…
>
> BTW, why don’t you want just to introduce interrupt threads with dedicated
> stacks??? Interrupt handler stubs will mask of a given interrupt the way
> it is appropriate for given HAL, and give a scheduler a chance to decide
> what has to be processed first. The very first thing that gets into ones
> head is the additional overhead, but, according to Solaris papers, in
> actuality, it somehow resulted in overall performance improvement when
> interrupt threads got introduced to Solaris…
>
> Anton Bassov
>

11

> I suspect that the change to the driver contract would be too much to bear.

DEFINITELY not…

The only “change” that drivers will perceive is the ability to make blocking calls in ISRs and DPCs. The rest can be done behind the scenes, so that it will remain totally transparent to drivers - the only ones who have to know about it are ntoskrnl.exe and hal.dll…

Anton Bassov