Re: MSI interrupts

On Sun, 23 Mar 2025 16:16:16 +0000, EricP wrote:

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.

I remove that race condition by removing the need for FLIR (which I
call the dispatcher) to check. All the checks are done AT* the SVR
instruction. (*) and during

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.

How to know:: It COULD look at the value in its stack pointer. An
empty stack implies it is leaving, a non-empty stack implies it
has more to do.
But in practice, it does not need to know as interrupts are properly
nested and serviced in priority order.

There are a number of non-interruptible checks and control flag changes
that supervisor return must perform.
>
To do this I have a single instruction CSVR Conditional Supervisor
Return
which handles all interrupt, exception, and SysCall returns. It performs
a model specific test on an interrupt control register and if True
changes
the ICR state and returns to the prior context. If False makes other ICR
state changes and falls through the CSVR instruction where code can
determine what just changed. This would typically be a jump into the OS
Dispatcher to flush any DPC/SoftIrq and check for thread rescheduling.
This whole return sequence is performed without having to disable
interrupts.

I, too, have a single instruction (SVR) that delivers control to the
highest priority still pending thread, regardless of whether it is
a new interrupt, a scheduled DPC/softIRQ, a local timer, an IPI, or
the thread the interrupt stack was placed upon.
SVR looks at the priority of the thread to receive control, and the
priorities of pending 'interrupts' (of which DPC/softIRQ and IPIs
are part) and transfers control to the highest priority pending
thread--occasionally that thread is the interrupted one.
Should a higher priority thread become pending while SVR is in progress,
the higher priority thread will receive control before the first inst-
ruction of the mis-receiving thread is performed.
As far as you have explained these things to me, I see no race
conditions
in the architected means.