Re: MSI interrupts

MitchAlsup1 wrote:

On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote:
>

In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>
But let me turn it around, what real-world problem does this
interrupt prioritization scheme solve coupled with the inability
to disable interrupts solve?

>
The OS does not have to "walk" its schedule queues in order to
context switch.
>
The SVR (SuperVisor Return) instruction checks the priority of
the thread that had been interrupted, and if it is of lower
priority than what is pending in the interrupt table, the
one on the interrupt table receives control while the lower
priority thread remains interrupted.
>
Thus, the return path from an ISR, just does an SVR. If a
DPC/softIRQ has been setup, or another interrupt has become
pending, HW chooses the path--acting as if HW returned control
to the interrupted thread, and then immediately took the inter-
rupt of highest priority still pending--without having executed
a single instruction in the interrupted thread.
>

                              Is anyone complaining that the
ability to disable interrupts is somehow a serious burden?

>
This thread started with the notion of MSI interrupts and the
inherent need to DI upon arrival at ISR dispatcher. This sub-
thread is investigating whether one can perform ISRs without
disabling interrupts. Thus, making IDisablement an unnecessary
part of interrupt servicing itself.
>
Your (and EricP)'s contribution is to annotate those instances
where one can arrive at an ISR IE and still want/need to DI and EI
independent of the control transfer from and back to interrupted
thread (even if control arrives reentrantly from interrupted thread).

 Supervisor return, whatever it is called - sysret, rei, svr -
is traditionally another point where a number of OS race conditions
can force it to briefly disable interrupts.
 The classic case is when a DPC/SoftIrq may be posted by an Interrupt
Service Routine (ISR) and causes the First Level Interrupt Handler (FLIH),
which is the ISR nested first on the stack of priority interrupts,
to exit into the OS rather than return to its prior thread.
 The race condition occurs between the point when the FLIH ISR epilogue
checks for pending a pending DPC, and not finding one decides to return
to the prior thread. Between that check and the SVR instruction a higher
priority interrupt occurs and posts a DPC.
 Another race condition can be how does an epilogue know if it is a FLIH
or nested one? A counter for each core incremented by the ISR prologue
and checked by the epilogue would do but what if the nested interrupt
catches a lower level prologue just before it increments the counter.