Hi,
If two devices share the same IRQ number, do they always own the same DIRQL? If not, is it possible that one of the two device’s ISR preempt the other’s ISR execution?
Thanks for replies!
Patrick
> If two devices share the same IRQ number, do they always own the same DIRQL?
IOAPIC allows only one-to-one correspondence between interrupt pin and vector number that it maps to. Therefore, if two devices share interrupt pin they will automatically share vector, and interrupt priority is implied by vector number. This means that, as long as the OS relies upon TPR in implementation of IRQL concept, these devices will have the same IRQL
However, AFAIK, newer Windows versions (IIRC, starting from W2K3 SP 2) came back to implementing the concept of IRQL in a software, which, depending on the way it is implemented, may break any correlation between vector number and ISR 's priority compared to other units of execution. Therefore, this is just the question of how Windows designers decided to handle it ( please note that their approach may change in the future)…
Anton Bassov
As usually, Anton provided a lot of details in order to impress you into
thinking that he’s an expert here. Please ignore him. His answer would
imply that you only get that behavior when using an I/O APIC.
Regardless of the interrupt controller used, there’s no way to differentiate
an interrupt from two devices which are physically sharing an IRQ (at least
not without running the ISRs, which can then look at the devices*.)
Consequently, the ISRs must run at the same IRQL or they could pre-empt one
another. And if they could pre-empt one another, they could hang the
system.
* Newer PCI devices may implement the “Interrupt Disable” and “Interrupt
Status” bits. This would theoretically allow NT to discover which device
was interrupting without calling an ISR. But since these are spottily
implemented and because reading configuration space is very expensive, we
don’t do that.
P.S. Anton, I know that you will reply to this. I’m not going to read your
reply. So to anybody reading this thread, if I don’t respond to him, it’s
not necessarily because I agree with him.
–
Jake Oshins
Hyper-V I/O Architect (former interrupt guy)
Windows Kernel Team
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
>> If two devices share the same IRQ number, do they always own the same
>> DIRQL?
>
>
> IOAPIC allows only one-to-one correspondence between interrupt pin and
> vector number that it maps to. Therefore, if two devices share interrupt
> pin they will automatically share vector, and interrupt priority is
> implied by vector number. This means that, as long as the OS relies upon
> TPR in implementation of IRQL concept, these devices will have the same
> IRQL
>
> However, AFAIK, newer Windows versions (IIRC, starting from W2K3 SP 2)
> came back to implementing the concept of IRQL in a software, which,
> depending on the way it is implemented, may break any correlation between
> vector number and ISR 's priority compared to other units of execution.
> Therefore, this is just the question of how Windows designers decided to
> handle it ( please note that their approach may change in the future)…
>
> Anton Bassov
>
Jake,
Anton, I know that you will reply to this.
Well, if you , indeed, DID know what my reply may possibly be like (no, there is nothing personal in it as you seem to expect - unlike you, I prefer to argue with people on the technical grounds and to avoid personal stuff whenever it is possible) you would not have made the statement below:
[begin quote]
Regardless of the interrupt controller used, there’s no way to differentiate an interrupt from two devices which are physically sharing an IRQ (at least not without running the ISRs, which can then look at the devices*.) Consequently, the ISRs must run at the same IRQL or they could pre-empt one another. And if they could pre-empt one another, they could hang the system.
[end quote]
The problem is that , as long as you handle things in a software, the above statement is simply wrong, and you don’t seem to realize it - you just don’t seem to be familiar with the concept of interrupt threads. To give you an idea, consider the following approach:
-
Your device registers interrupt handler of a given priority with some “interrupt dispatcher” that is implemented by the OS totally in a software. Among other things like scheduling ISRs, this dispatcher provides handler stubs
-
When interrupt occurs, handler stub acknowledges interrupt to the controller by issuing EOI straight away, disables IRQ ( this step is necessary otherwise you will get into a storm with level-triggered interrupts - you issue EOI before actually having handed interrupt) ,re-enables interrupts on the given CPU, and transfer control to the dispatcher that actually schedules ISR.
-
ISR gets invoked. This does not necessarily happen immediately - it is up to your scheduler to decide when it should get invoked (it is understandable that IRQ remains in disabled state until interrupt gets handled by ISR). If it handles interrupt dispatcher re-enables IRQ, otherwise it invokes another ISR
that is associated with a given vector
If you think about it carefully you will realize that with such approach you can easily break any connection between interrupt priority as implied by the hardware and the one of your ISR. If ISRs for devices X and Y that share the same are IRQ are assigned different priorities, can one pre-empt another? If you think about it carefully you will realize that it just cannot happen - once you have disabled IRQ device X will be just unable to raise interrupts until interrupt raised by device Y gets handled, so that the whole thing synchronizes itself…
As you can see, implementing things in a software opens more possibilities that you seem to be aware of…
I’m not going to read your reply.
Well, this is you choice. To be honest, I don’t really care - if you believe that you already know everything so that you just don’t need to know anything else, what can I possibly do here ( and, which is more important, why should I try to do anything, in the first place)??? Therefore, my post is targeted towards those who want to know things…
Anton Bassov
I always like it when somebody takes it upon himself to lecture one of the guys who has been responsible for implementing much the Windows interrupt architecture… on how INTERRUPTS work on WINDOWs.
You wanna lecture Jake about electric cars? Fine. But lecturing Jake on interrupts is just plain silly.
Thread closed. No more replies please, and don’t start this topic in another thread.
Peter
A Slave To The List