IRQ, IRQL, intel docs and windows....

NTDEV
1

Hi
I really confused about IRQ, IRQL and interrupt priorities in intel documentation and windows programming books.

1-) In Intel doc.
Interrupt No. Exception

0 Divide Error

1 DEBUG TRAP

2 NMI/NPX Error

3 Breakpoint

4 Overflow

5 BOUND/Print Screen

6 Invalid Opcode

7 NPX Not Available

8 Double Exception

9 NPX Segment Overrun

A Invalid Task State Segment (TSS)

B Segment Not Present

C Stack Fault

D General Protection

E Page Fault

F Intel Reserved

10 Floating Point

11 Alignment Check

20-31(binary) Reserved
32-255 user Defined External or INT n instruction.

But in IBM PC IRQs are:

line interrupt function

IRQ0 08 system timer
IRQ1 09 keyboard
IRQ2 0A PC/XT: EGA vertical retrace or maybe available
PC/AT: see explanation below
IRQ3 0B COM2 or maybe available
IRQ4 0C COM1
IRQ5 0D PC/XT: hard disk drive
PC/AT: LPT2 or maybe available
IRQ6 0E floppy disk drive
IRQ7 0F LPT1
IRQ8 70 PC/AT: CMOS Real Time Clock
IRQ9 71 PC/AT: see explanation below
IRQ10 72 PC/AT: probably available
IRQ11 73 PC/AT: probably available
IRQ12 74 PC/AT: probably available
PS/2: mouse
IRQ13 75 PC/AT: numeric coprocessor
IRQ14 76 PC/AT: hard disk drive
IRQ15 77 PC/AT: probably available

There is a interferes with exceptions, so we need to remap the IRQs to a different block of interrupt numbers.Between 32-255. Right?

But these interrupt numbers don’t have relationship with interrupt and exception priorities. Because Intel manual says:

Table 5-2. Priority Among Simultaneous Exceptions and Interrupts

Priority Description
1 (Highest) Hardware Reset and Machine Checks

  • RESET
  • Machine Check

2 Trap on Task Switch

  • T flag in TSS is set

3 External Hardware Interventions

  • FLUSH
  • STOPCLK
  • SMI
  • INIT

4 Traps on the Previous Instruction

  • Breakpoints
  • Debug Trap Exceptions (TF flag set or data/I-O breakpoint)

5 Nonmaskable Interrupts (NMI)

6 Maskable Hardware Interrupts

7 Code Breakpoint Fault

8 Faults from Fetching Next Instruction

  • Code-Segment Limit Violation
  • Code Page Fault

9 Faults from Decoding the Next Instruction

  • Instruction length > 15 bytes
  • Invalid Opcode
  • Coprocessor Not Available

10 (Lowest) Faults on Executing an Instruction

  • Overflow
  • Bound error
  • Invalid TSS
  • Segment Not Present
  • Stack fault
  • General Protection
  • Data Page Fault
  • Alignment Check
  • x87 FPU Floating-point exception
  • SIMD floating-point exception

But this prioty scheme doesn’t have any relationship with windows because windows uses IRQL

In one of OSR article:

"WAIT! Doesn’t IRQ == Interrupt Priority?

Not in Windows it doesn’t, even if the hardware documentation tells you differently. Depending on your configuration, you are either using a programmable interrupt controller (PIC) or an advanced programmable interrupt controller (APIC). If you have read the article on interrupts in this issue, you already know that the INTIN lines of the APIC have no implied priority, but that the IRQ lines of the PIC do have an implied priority. This would probably lead you to believe that your device’s IRQ (and therefore your PIC priority) has a direct relation to your IRQL (and thus your device’s interrupt priority). But, you’d be wrong. This is a common misconception and it’s time for everyone out there to forget it! Where, how, when, and why your device connects to a PIC makes absolutely no difference in terms of your device’s priority in Windows.

For example, say you’re running on a system with a PIC. Device X connects to IRQ3 and device Y connects to IRQ7. If Windows just let the PIC be, X’s interrupts would always take precedence over Y’s because its IRQ has a higher (hardware interrupt) priority. However, Windows does not use the implied hardware interrupt priorities in the PIC to prioritize its interrupts. So, it could very well be that IRQ7 has an higher IRQL than IRQ3 on your system.

On Windows, the IRQ of your device never dictates the associated level of urgency of your device’s interrupt. Period. Full stop. And this is true whether you’re running on a system with a PIC or you’re on a system with an APIC. What can you do to influence this? Well, really, nothing (short of writing your own HAL, and don’t even try to go there, my friend). It’s just the way Windows works."

1-) Must i omit Intel manuals interrupt priority schema? If OS designers will/must use another priority schema. Why does intel give priority scheme?

2-) I really confused about IRQLs, IRQs and exceptions. What is the IRQLs of exceptions(Interupt No:0-31) in windows?
If there is an exception(for example: Overflow) occurs with IRQL=high, can this interrupt Maskable Hardware Interrupts? Although Table 5-2(above) Maskable Hardware Interrupts priority is higher than overflow…

4-) Is there a documented interrupt priority table for windows? (like intel’s table 5-2)

3-) I am reading Windows internals and Understanding IRQL article. Do you have any advice me to read something else to understand this?

I will be very glad, if you help me to find answers…

Thanks…

2

> There is a interferes with exceptions, so we need to remap the IRQs to a different block

of interrupt numbers.Between 32-255. Right?

Well, we have to map IRQs to interrupt vectors anyway. Once vectors 0-32 are reserved, we have to map them to higher vectors…

What is the IRQLs of exceptions(Interupt No:0-31) in windows?

Basically, there are maskable interrupts, on one hand, and unmaskable interrupts and exceptions on another. The former ones may be temporarily disabled by the software, but the latter ones may not. All interrupts that come from hardware devices are maskable. Maskable interrupts can be disabled *on a given CPU* either completely in one go by clearing IF flag in EFLAGS (CLI instruction), or up to some certain priority level by writing to CPU local APIC’s Task Priority Register(TPR). This is when the concept of IRQL comes into play. Basically, IRQL is just an index into the array of values to be written to TPR (I assume APIC HAL here). CPU temporarily disables delivery of interrupts of priority below the one that is currently specified in TPR. Exceptions are received by the CPU regardless of either TPR’s or IF flag’s state, so that the concept of IRQL does not apply to them.

If there is an exception(for example: Overflow) occurs with IRQL=high, can this
interrupt Maskable Hardware Interrupts?

Sure…

Although Table 5-2(above) Maskable Hardware Interrupts priority is higher than overflow…

The confusing thing here is that the group of maskable hardware interrupts includes the reserved inter-
rupt and exception vectors 0 through 32. Theoretically any of these vectors can be delivered to the CPU through the INTR pin ( and any of the vectors from 16 through 32 through the local APIC). However, this is not really an exception - it is an interrupt , so that the state of hardware does not correspond to that of the exception (for example, error code is not pushed on the stack, i.e. something you would get if you invoked exception handler with INT n instruction). Therefore, you can mask these vectors only as interrupts but not as exceptions…

Anton Bassov

3

>specified in TPR. Exceptions are received by the CPU regardless of either
TPR’s

or IF flag’s state, so that the concept of IRQL does not apply to them.

Exceptions are not “received”, the occur as a direct result of some opcode
execution. They are not sent by some other party.

Exceptions are common with interrupts only in that they are also delivered
using IDT gates. Nothing common anymore, and the notion of IRQL has nothing to
do with exceptions.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

4

Sercan,

More detail on the relationship of IRQ and IRQL for *interrupts*. The replies so far are correct - exceptions are a very different animal that do not have priority or maskability.

For interrupts, however, here’s how I think of IRQ vs IRQL. IRQ (at least the way the term is used inside Windows, in resource descriptors, etc) represents a device interrupt request. Before MSI, this basically meant an input to an interrupt controller. This terminology goes back to the PIC, where an input to the PIC was called an IRQ. So in a PIC system if something were connected to pin 8 of the PIC, this would be represented by IRQ 8 in Windows. Once you get into cascading PICs and multiple I/O APICs, the original PIC term doesn’t directly apply anymore, but the general definition is still: IRQ represents a interrupt controller input. Devices that are wired together on the motherboard and share an input to the interrupt controller share an IRQ. With MSI there’s no interrupt controller involved, but that doesn’t change the concept much.

IRQL is a Windows-specific term that refers to a processor priority level. On x86, processor priority of an interrupt is determined by the vector number targeted by the interrupt. Higher vector numbers, higher priority.

In some cases, IRQ and IRQL are directly related. In the PIC, there was a single vector base that the IRQ was added to, producing the vector number interrupted by that IRQ. That means higher IRQ, higher IRQL. (As you noted, this base has to be above 30 so that it doesn’t interfere with the built-in exceptions.) In other cases, the concepts are not as directly related. An I/O APIC input can interrupt any processor, at any vector. So a low numbered IRQ can be assigned any arbitrary IRQL in an APIC environment. Different architectures might implement these concepts completely differently.

This is just different words for what the OSR article was saying, but possibly helpful.

Dave

5

> Exceptions are not “received”, the occur as a direct result of some opcode execution.

They are not sent by some other party.

There is an exception (no pun intended) to the above rule - Machine-Check Exception (INT 18) may be sent to the CPU by the external agent…

Anton Bassov

6

> IRQL is a Windows-specific term that refers to a processor priority level.

Actually, it is not Windows-specific at all - UNIX concept of splx() is dated back to 1970s…
IIRC, few moths ago Don claimed that IRQL is very different from splx() , because the former is purely
purely in a software while the latter one is hardware concept… Although it may be true for PIC machines,
on APIC ones IRQL is manipulated with via local APIC’s TPR, so that it is the same old slpx(). The only difference is that modern UNICes abandoned it (for example, Linux ignores TPR completely after having set it at the boot time) while Windows still sticks to it.

IMHO, the “golden mean” lies somewhere in between. For example, handler stubs in IDT could just issue EOI, disable target IRQ, and queue ISR to be executed in context of a software interrupt with all maskable
interrupts enabled ( it is understandable that the vector for this software interrupts has to be below that of alll hardware interrupts). After ISR for a given IRQ returns 1, IRQ would get re-enabled so that device can interrupt again (all DPCs would be executed in context of yet another software interrupt on even lower priority)…

Anton Bassov

7

First, let me say that I almost never have a reason to bother to
follow up on what Dave Walker writes. He is usually really, really
careful and thorough. But in this case, Dave my esteemed colleague,
you need to go read the PIC HAL again.

First, if you’re only talking about a single, non-cascaded PIC, then
there is no “pin 8.” There are only pins 0 through 7.

Second, while it is true that there is a native priority scheme with a
PIC, Windows (NT and all follow-ons, not DOS/Win9x) subverts this
priority scheme when it lays the concept of IRQL over top of a PIC.
We had to do this because the typical layout of IRQs in a PC tends to
put devices with low latency tolerances at the wrong end of a PIC’s
priority scale.

So the PIC HALs have a table in them where each IRQL masks a set of
IRQs. Each higher IRQL masks a larger superset of the IRQs than all
lower IRQLs. When you change IRQL, a new mask is written* into the
PIC, changing the set of IRQs that might be triggered.

In summary, there is no obvious relationship between the IRQ number
and IRQL on a PIC HAL, except that we’ve forced sensitive devices like
serial ports and IDE controllers to the higher IRQLs.

  • Jake Oshins
    Windows Interrupt Guy

* Note that some PIC HALs have historically skipped some updates to
the PIC mask with a scheme called “Lazy IRQL” for performance reasons.
Logical operation doesn’t change, though.

wrote in message news:xxxxx@ntdev…
> Sercan,
>
> More detail on the relationship of IRQ and IRQL for interrupts.
> The replies so far are correct - exceptions are a very different
> animal that do not have priority or maskability.
>
> For interrupts, however, here’s how I think of IRQ vs IRQL. IRQ (at
> least the way the term is used inside Windows, in resource
> descriptors, etc) represents a device interrupt request. Before
> MSI, this basically meant an input to an interrupt controller. This
> terminology goes back to the PIC, where an input to the PIC was
> called an IRQ. So in a PIC system if something were connected to
> pin 8 of the PIC, this would be represented by IRQ 8 in Windows.
> Once you get into cascading PICs and multiple I/O APICs, the
> original PIC term doesn’t directly apply anymore, but the general
> definition is still: IRQ represents a interrupt controller input.
> Devices that are wired together on the motherboard and share an
> input to the interrupt controller share an IRQ. With MSI there’s no
> interrupt controller involved, but that doesn’t change the concept
> much.
>
> IRQL is a Windows-specific term that refers to a processor priority
> level. On x86, processor priority of an interrupt is determined by
> the vector number targeted by the interrupt. Higher vector numbers,
> higher priority.
>
> In some cases, IRQ and IRQL are directly related. In the PIC, there
> was a single vector base that the IRQ was added to, producing the
> vector number interrupted by that IRQ. That means higher IRQ,
> higher IRQL. (As you noted, this base has to be above 30 so that it
> doesn’t interfere with the built-in exceptions.) In other cases,
> the concepts are not as directly related. An I/O APIC input can
> interrupt any processor, at any vector. So a low numbered IRQ can
> be assigned any arbitrary IRQL in an APIC environment. Different
> architectures might implement these concepts completely differently.
>
> This is just different words for what the OSR article was saying,
> but possibly helpful.
>
> Dave
>

8

Anton, when I said that IRQL is a Windows-specific “term” I mean that the specific acronym is a Windows thing. The concept of interrupt priority is clearly not Windows-specific.

Jake, quite right on all accounts. My examples were sloppy. I believe the definitions of the terms and their relationship are right, but thanks for correcting me. I forgot about that PIC mask table.

Dave

9

Thanks for all answers.They are really very helpful.

OK. IRQL is not related with exceptions which are generated by CPU itself.
And Windows imposes its own interrupt priority scheme known as IRQL. and as
Anton Bassov said :“Exceptions are received by the CPU regardless of either
TPR’s or IF flag’s state, so that the concept of IRQL does not apply to
them”

There are too many different interrupt priority lists in the internet. All
of them are different from intel manuls. For example one of them said:

  1. Reset: caused by change in voltage on RESET input pin
  2. Internal interrupts: caused by executing certain non-flow control
    instructions.
  3. Software interrupts: caused by executing INT instruction.
  4. Non-maskable interrupt: Caused by change in voltage on the NMI pin.
  5. External hardware interrupts: Caused by change in voltage on the INTR pin
    The order of the five interrupt classed listed above is the same as their
    priority order.
    Reset has the highest priority and external hardware interrupts the lowest.

The other said:

Lower interrupt vectors have higher priority
Lower priority can’t interrupt higher priority
Higher priority can interrupt lower priority
ISR for INT 21h is running
Computer gets request from device attached to IRQ8 (INT 78h)
INT 21h procedure must finish before IRQ8 device can be serviced
ISR for INT 21h is running
Computer gets request from Timer 0 IRQ0 (INT 8h)
Code for INT 21h gets interrupted, ISR for timer runs immediately, INT21h
finishes afterwards
* <gloss.html>*
This one more resource:

1-)divide error interrupt, INT n, INT0 highest
2-)NMI
3-)INTR
4-)TRAP flag (single step)
lowes

And intel’s manual different, too. I know that i must read only intels
manual.

I want to ask this:

Is MS use Intels priority list (Table 5-2. Priority Among Simultaneous
Exceptions and Interrupts)?
Maybe; i must ask this: Is a system programmer must obey the Table 5-2 in
intel manual?

Now , i know that: “However, Windows does not use the implied hardware
interrupt priorities in the PIC to prioritize its interrupts. So, it could
very well be that IRQ7 has an higher IRQL than IRQ3 on your system.”

I asked: “If there is an exception(for example: Overflow) occurs with
IRQL=high, can this interrupt Maskable Hardware Interrupts?”
Anton Bassov said : “Sure”

But i expected to read: " No, IRQL and exceptions are irrelevant; so
exceptions haven’t got IRQL; high or low". Am i wrong?

If i am right; Windows uses its own scheme for hardware interrupts;
How can Windows determine what must be done when an interrupt and exception
occurs at the same time?
Interrupt has IRQL but this hasn’t any meaning for exceptions. So windows
can’t compare interupts and exceptions? Wrong/Rgiht?

What is the parameter does windows have so windows can compare interrupt and
exception and determine which one has high priority than other? For example:
There is an interrupt from hardware device and also there is an overflow
exception, which ones ISR will be called? and How can Windows determine?

Thanks again for all answers…</gloss.html>

10

> * Note that some PIC HALs have historically skipped some updates to

the PIC mask with a scheme called “Lazy IRQL” for performance reasons.

Does this mean - emulation the interrupt mask in the memory variable by using
the “enabled interrupts” mask and “fired-but-not-serviced-due-to-priority
interrupts” mask?

This seems to be a good idea for me, given the slow speed of port 0x20.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

11

> I asked: “If there is an exception(for example: Overflow) occurs with IRQL=high, can this interrupt Maskable > Hardware Interrupts?” Anton Bassov said : “Sure” But i expected to read: " No, IRQL and exceptions are >irrelevant; so exceptions haven’t got IRQL; high or low". Am i wrong?

The way I understood your question, you were asking whether ISR that runs at RQL=high can get interrupted by exception that it generates. Therefore, you got the answer you expected - exception will fire regardless of IRQL of the code that generates it…

What is the parameter does windows have so windows can compare interrupt and exception and >determine which one has high priority than other? For example: There is an interrupt from hardware >device and also there is an overflow exception, which ones ISR will be called? and How can Windows > determine?

It is not the OS who has to determine it - it is CPU hardware who decides what has a higher priority. As you can see from the table that you have provided yourself, CPU will raise interrupt first, because maskable interrupts have higher priority than overflow exception…

What I would advise you to do is to read Volume 3a of Intel Developer’s Manual - it explains everything in detail. Just keep in mind that IRQL is just a value to be written to local APIC’s TPR, so that everything will become clear to you…

Anton Bassov

12

Mostly. It’s a little more complicated than that.

  • Jake

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> * Note that some PIC HALs have historically skipped some updates to
>> the PIC mask with a scheme called “Lazy IRQL” for performance
>> reasons.
>
> Does this mean - emulation the interrupt mask in the memory variable
> by using
> the “enabled interrupts” mask and
> “fired-but-not-serviced-due-to-priority
> interrupts” mask?
>
> This seems to be a good idea for me, given the slow speed of port
> 0x20.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

13

Serim, you have a bunch of questions in this post, many of which seem
to be based on misconceptions.

I have two suggestions. First, just think about programming to the
abstraction that Windows gives you with respect to interrupts. If you
stay within that, it works regardless of the details you’re asking
below. It works on a PIC HAL, an APIC HAL. It even works on non-x86
processors. In the past, we’ve supported MIPS, Alpha AXP, PowerPC and
there were even ports to other chips that never saw the light of day
(yet.)

Second, how about asking us a question that’s rooted in a concrete
problem that you’re trying to solve at the moment? We’ll answer it
and perhaps you’ll get to move on.

  • Jake

“serimc” wrote in message news:xxxxx@ntdev…
Thanks for all answers.They are really very helpful.

OK. IRQL is not related with exceptions which are generated by CPU
itself. And Windows imposes its own interrupt priority scheme known
as IRQL. and as Anton Bassov said :“Exceptions are received by the CPU
regardless of either TPR’s or IF flag’s state, so that the concept of
IRQL does not apply to them”

There are too many different interrupt priority lists in the internet.
All of them are different from intel manuls. For example one of them
said:
1) Reset: caused by change in voltage on RESET input pin
2) Internal interrupts: caused by executing certain non-flow control
instructions.
3) Software interrupts: caused by executing INT instruction.
4) Non-maskable interrupt: Caused by change in voltage on the NMI pin.
5) External hardware interrupts: Caused by change in voltage on the
INTR pin
The order of the five interrupt classed listed above is the same as
their priority order.
Reset has the highest priority and external hardware interrupts the
lowest.

The other said:

Lower interrupt vectors have higher priority
Lower priority can’t interrupt higher priority
Higher priority can interrupt lower priority
ISR for INT 21h is running
Computer gets request from device attached to IRQ8 (INT 78h)
INT 21h procedure must finish before IRQ8 device can be serviced
ISR for INT 21h is running
Computer gets request from Timer 0 IRQ0 (INT 8h)
Code for INT 21h gets interrupted, ISR for timer runs immediately,
INT21h finishes afterwards

This one more resource:

1-)divide error interrupt, INT n, INT0 highest
2-)NMI
3-)INTR
4-)TRAP flag (single
step) lowes

And intel’s manual different, too. I know that i must read only intels
manual.

I want to ask this:

Is MS use Intels priority list (Table 5-2. Priority Among Simultaneous
Exceptions and Interrupts)?
Maybe; i must ask this: Is a system programmer must obey the Table 5-2
in intel manual?

Now , i know that: “However, Windows does not use the implied hardware
interrupt priorities in the PIC to prioritize its interrupts. So, it
could very well be that IRQ7 has an higher IRQL than IRQ3 on your
system.”

I asked: “If there is an exception(for example: Overflow) occurs with
IRQL=high, can this interrupt Maskable Hardware Interrupts?”
Anton Bassov said : “Sure”

But i expected to read: " No, IRQL and exceptions are irrelevant; so
exceptions haven’t got IRQL; high or low". Am i wrong?

If i am right; Windows uses its own scheme for hardware interrupts;
How can Windows determine what must be done when an interrupt and
exception occurs at the same time?
Interrupt has IRQL but this hasn’t any meaning for exceptions. So
windows can’t compare interupts and exceptions? Wrong/Rgiht?

What is the parameter does windows have so windows can compare
interrupt and exception and determine which one has high priority than
other? For example: There is an interrupt from hardware device and
also there is an overflow exception, which ones ISR will be called?
and How can Windows determine?

Thanks again for all answers…

14

> Second, how about asking us a question that’s rooted in a concrete problem that you’re

trying to solve at the moment?

Actually, judging from his question, the OP just wants to understand how it all works (which becomes more and more uncommon in the Windows world these days)…

Anton Bassov

15

> The concept of interrupt priority is clearly not Windows-specific.

Well, it looks more and more like these days it is (although I am not so sure about VMS)…

I think that if Windows did not make any use of it, Intel would just abandon the whole thing the way it abandoned segmentation (all segment bases, apart from FS and GS are assumed to be zero) and hardware tasks (GPF gets raised if IDT descriptor points to TSS) on x86_64 -all major OSes ignore these x86 features, so that Intel decided no to take them to x86_64…

Anton Bassov

16

“you have a bunch of questions in this post, many of which seem to be based
on misconceptions.”

Yes, right. Both your explanations(especially Anton Bassov) and
Understanding the Linux Kernel’s 4.2.1. IRQs and Interrupts section help me
very much and understood…

Thanks…

17

> Understanding the Linux Kernel’s 4.2.1. IRQs and Interrupts

Please note that Linux has no concept of IRQL, and, in general, has a very different approach to interrupts dispatching. Therefore, be careful - otherwise, instead of resolving your already existing misconceptions, information about Linux kernel may well result in the additional ones…

Anton Bassov

18

>that Intel decided no to take them to x86_64…

Sorry: “AMD decided not to take them to x86_64” - x64 is AMD’s design.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

19

> Please note that Linux has no concept of IRQL, and, in general, has a very

different approach to interrupts dispatching.

When I last read the Linux kernel - 2.3 - they had nearly the same, with DPCs
called “bottom halves”. Unlike Windows, where there can be arbitrary DPCs,
Linux only had a predefined array of bottom halves - net_bh() and so on.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

20

BTW, Jake, am I correct that Level interrupt parameter is the (A)PIC input
wire number, while the Vector parameter is the IDT vector number?

Am I correct that the IRQL on which the ISR will run is 100% determined
only by the IDT vector number, in other words - each IDT vector has its
hard-coded IRQL?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com