Confused about x86 device IRQ nesting

[fredericvo]

Hello and sorry if this is in the wrong section or if it has been asked before but I'm new to this forum and haven't been able to find a definitive answer to this particular source of confusion.
I'm not trying to create an OS but I'm learning about WDM & Linux device driver development, and also reading the Intel System Programming Manuals.
Here is what confuses me:

The Intel manuals and also the wiki on this forum and several other places online mention that an Interrupt Gate DISABLES IRQs upon entry and enables them again after leaving the ISR. (pops up the EFLAGS)
However, Linux as well as Windows literature suggests that IRQs can be preempted by other, higher priority, IRQs (sometimes it seems there aren't even real hardware priorities and any IRQ can preempt another but the priority is enforced with software trickery, (I'm not even sure how the whole IRQL business is implemented on Windows) )
So IRQs clearly seem to be nested.

Sample ISRs always take this form though:

Code: Select all

isr:
 pusha
 push gs
 push fs
 push es
 push ds
[b]; absence of a sti instruction to enable IRQs again, is this even allowed/recommended?[/b]
 ; do what you want to here :)

 pop ds
 pop es
 pop fs
 pop gs
 popa
 iret

What is it that I'm misunderstanding?

[zaval]

they are masked out. I am far away from x86 APIC/LAPIC/SAPIC/WhateverAPIC, but the idea is that there is 1 or 2 IRQ lines from the interrupt controller to the processor, and a bunch of irqs from devices to the interrupt controller. those are different. Disabling you mention is disabling the fiirst. processor doesn't want to listen to PIC at this time. IRQLs are masking the second ones. that bunch of device (and software as well) irqs are prioritized inside of PIC, by masking some of them out when the other of the higher priority fires. let's say the irq from the system timer is at the higher IRQL than from UART. So when the timer irq fires, OS interrupt dispatcher masks out UART irq and others that are of the lower priority than the system timer's irq. only when interrupt dispatcher is messing around with the interrupt controller, masking out irqs, it disables CPU IRQ in order to not get invoked reentrantly, I doubt intrerrupt dispatchers could be reentrant. it's a quick time, it's not ISR, it's an interrupt dispatching routine. It calls the appropriate ISR with interrupts enabled. it's all very architecture dependent, so I might write too unclear for the x86 realm.
On the mips machine I program, interrupt controller has 64 interrupt sources, and you can easily mask each of them out as you wish, so there is no hardware/software distinction for IRQLs, it's a mechainsm for prioritizing device and software interrupts.
Of course, there is another level of irq masking - a device itself.
1) Processor could disable its listening to its irq line(s) (arm has irq and fiq). (interrupt dispatching)
2) interrupt controller has a lot of irq sources representing interrupts from devices (IRQL)
3) devices have its own distinction between what exactly caused irq inside of them as well as ability of irq masking. (ISR/DPC).

[fredericvo]

But before it matters that they are masked/unmasked in the (A)PIC I assume an STI instruction has to be issued in the ISR, right?
I believe I have seen one webpage vaguely talking about enabling interrupts in an interrupt gate's handler.

[zaval]

But before it matters that they are masked/unmasked in the (A)PIC I assume an STI instruction has to be issued in the ISR, right?
I believe I have seen one webpage vaguely talking about enabling interrupts in an interrupt gate's handler.

ISR it's a driver routine for servicing interrupts from a particular device. Generally, it should not bother itself with enabling/disabling interrupts on the CPU.

[fredericvo]

I mean the main handler then.

[fredericvo]

OK nvm I found the answer in the book "Understanding the Linux kernel"

s. Remember that the _ _do_IRQ( ) function runs with local interrupts disabled; in fact, the CPU control unit automatically clears the IF flag of
the eflags register because the interrupt handler is invoked through an IDT's interrupt gate. However, we'll
see shortly that the kernel might re-enable local interrupts before executing the interrupt service routines of
this interrupt.
When using the I/O APIC, however, things are much more complicated.

Question solved.