7

As x86 computers shifted from 32-bit to 64-bit, they also shifted from using 8259-style Programmable Interrupt Controllers with 8 interrupt lines. (Or two multiplexed PICs for a total of 15 interrupt lines.) Then, if you were to install 32-bit Windows for an operating system, Windows would implement 32 software IRQLs (Interrupt Request Levels) with IRQLs 3 through 26 (or so) being reserved for devices.

Then the x64 platform came along. You need a machine with an APIC, which has 256 interrupt lines, in order to install 64-bit Windows on it. However, 64-bit Windows only implements 16 IRQLs.

So my question is, does anyone know why 64-bit Windows would implement fewer IRQLs than its 32-bit counterpart even though it has many more hardware interrupt lines at its disposal?

1

Because with a DOS type system you broadly needed an IRQ for each event and so lots of IRQ levels to allow events to mask other events simply. With a real OS you pretty much just need a single event and let the kernel figure everything else out (actually it's convenient to have a couple of levels for NMI and real-time).

So I'm guessing that with 64bit and knowing that you aren't backward compatible supporting some DOS app on a 386 they took the opportunity to simplify.

  • How can a "real OS" fix a hardware deficiency? – user1249 Aug 7 '12 at 18:59
  • @ThorbjørnRavnAndersen if the OS has proper kernel and protected hardware devices it can deal with any event in the kernel rather than having the CPU IRQL deal with different events happening at the same time – Martin Beckett Aug 7 '12 at 19:37
  • The original PC-architecture did not have that... – user1249 Aug 7 '12 at 19:46
  • 1
    From what I recall, the IBM PC configured the 8259 for edge-triggered interrupts, which had the rather annoying side-effect of making it very difficult to reliably share interrupt lines among multiple sources. If two devices X and Y shared an interrupt line, and Y wanted to interrupt the CPU, it would drive the interrupt line until it was serviced. If the ISR polled X, observed that it wasn't causing an interrupt, and then polled Y and handled its interrupt, and if before Y handled its interrupt X started asserting its interrupt output, then... – supercat Apr 21 '15 at 21:45
  • 2
    ...unless the ISR repolled X after servicing Y, no future interrupts from X or Y would ever get serviced. Had IBM used level-sensitive interrupts, then in the aforementioned situation, the fact that an interrupt was pending when the ISR returned would cause the interrupt handler to be re-invoked. Such a design makes interrupt sharing much safer. – supercat Apr 21 '15 at 21:47
0

I just want to add a couple more points about interrupts in a modern system. I will TRY to make the layout clearer.

The interrupt descriptor table (IDT) is the protected mode replacement for the interrupt vector table (IVT). The base address for the IDT is stored in a CPU register and it can be located almost anywhere in memory.

You can view the contents of the IDT if you have the kernel debugger by using the ! idt command. Apart from the expected 32 odd exception handlers and a few legacy devices you won't find much in the modern IDT. I will try to explain why later.

Every interrupt causes the CPU to enter kernel mode so kernel mode code can deal with them.

Interrupt request level (IRQL) zero is not really a level as all interrupts are allowed. User mode code usually runs at IRQL zero.

The kernel and drivers use software interrupts for issueing deferred procedure calls (DPC's), sheduleing threads and asynchronous procedure calls (APC's). DPC/thread dispatch is done at IRQL two and APC's at level one.

The kernel and drivers always try to keep the IRQL as low as possible. These days driver interrupt service routines often do little more than acknolage the interrupt before calling a DPC to carry out any data transfer. This way the IRQL can be dropped from device level as quickly as possible.

Sorry I said I would explain the lack of IDT entries but I have to go out. Message signalled interrupts, MSI-X and x2 local APIC are the cause. If anyone is interested please ask 😊

-2

Its a bit more complicated i'm afraid. Still haven't got to the bottom of it but i'll tell what I know. Windows maintains a note of the IRQL its using for EACH logical CPU in what it calls a processor control block which is just a data structure not any sort of register. There is also an interrupt descripter table with 256 entries that point eventually to interrupt service routines. I say eventually because first we go through an interrupt object that keeps a note of the interrupts assigned IRQL and also the interrupt despatcher. 32bit X86 CPU's did not have any notion of IRQL as such but the designers of Windows decided they would have 32 of them. The IRQL of a device was decided by taking its vector number and deviding it by 16. Remember the vector number is not the same as the IRQ pin number(any pin can have any vector between 32 and 255 because the first 32 vectors are reserved for exceptions). To make this work Windows has to program the PIC chip to mask out interrupt pins that are below the level that it has recorded for the CPU. This changed with X64 because the CPU was given a model specific register that actually set the CPU at an IRQL between 0 and 15. The designers of windows have made use of this to simplify things.

  • 1
    this post is rather hard to read (wall of text). Would you mind editing it into a better shape? – gnat Jul 5 '17 at 22:53
  • Sorry but writing is really NOT my strong suit. I could have included much more but it would have looked worse 🙄 – Wheels-of-Fire Jul 6 '17 at 0:06

protected by gnat Jul 6 '17 at 9:37

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.