If the interrupt is queued at the apic, irqls become a hardware-only
concern. No need whatsoever to bring the concept into the OS: the interrupt
prioritization is naturally ordered by the hardware, isr’s are blissfully
ignorant of what other isr’s are doing, and life goes on.
Alberto.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, December 29, 2007 3:17 AM
Subject: RE:[ntdev] Are callbacks guaranteed to run consecutively?
>
>>: the place to queue interrupts is in the APIC
>
> This is EXACTLY what Windows does - it raises IRQL to the appropriate
> level (i.e. writes the appropriate value to local APIC’s TPR) before
> invoking ISR, so that ISR may get interrupted only interrupts of priority,
> higher than the current one, and the ones of lower priority will get
> processed after ISR returns. However, it has nothing to do with a
> “conventional” spinlock that is being acquired and held at DPC level - no
> matter in which order ISRs get processed, they will all get processed
> before execution returns to the code that acquires/holds a spinlock…
>
>> independent of the code being executed by the processor.
>
> This is not the question of code - this is the question of IRQL, and
> interrupts just cannot be queued in APIC independently of current IRQL.
> Instead, everything depends on how interrupt’s priority fares against the
> IRQL that CPU currently runs at…
>
>> That’s what I mean when I say “do it fast”. Do not preempt - it’s
>> unnecessary
>
> In other words, what you are saying is “assign a code that acquires/holds
> the spinlock the highest possible interrupt priority (or just clear IF
> flag), no matter what and no matter how”. Not really wise approach, don’t
> you think???
>
> Anton Bassov
>
> —
> 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