Re: MSI interrupts

In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:

On Thu, 20 Mar 2025 12:44:08 +0000, Dan Cross wrote:
>

In article <af2d54a7c6c694bf18bcca6e6876a72b@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:

On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote:
>

In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:

I want to address the elephant in the room::
>
Why disable interrupts AT ALL !!

>
So that you can have some mechanism for building critical
sections that span multiple instructions, where just having
access to atomics and spin locks isn't enough.

>
You can do this with priority, too.

>
In the limit, disabling interrupts is just setting the priority
mask to infinity, so in some sense this is de facto true.  But I
don't see how having a prioritization scheme is all that useful.
Consider that when you're starting the system up, you need to
do things like set up an interrupt handler vector, and so on;

>
The Interrupt vector is completely software. HW delivers the MSI-X
message and the service for which this message is for, and SW decides
what to do with this message to that service provider. No HW vectoring
but HW does deliver all the bits needed to guide SW to its goal.

Maybe I'm missing the context here, and apologies if I am.  But
which interrupt disable are we talking about here, and where?  I
am coming at this from the perspective of systems software
running on some CPU core somewhere; if I want that software to
enter a critical section that cannot be interrupted, then it
seems to me that MSI-X delivery is just a detail at that point.
I might want to prevent IPIs, or delivery or local interrupts
attached directly to the CPU (or something like an IOAPIC or
GIC distributor).

In any event, if software isn't prepared to receive an interrupt
then there must necessarily be some mechanism to disable
interrupt delivery until it is.

surely you want to block all interrupts until you have done so.

>
I did not say I don't HAVE an interrupt disable, I state that one
receives control in an already reentrant state, so the typical
uses of ID are not in play--and I want to talk about the other
uses of ID. You are doing a fine job.

I suppose what I'm saying in part is that the "typical users"
all depend on the system's software architecture.  The ability
to handle nested interrupts at the hardware level is all well
and good, but doesn't matter if software can't handle it.

If your system model is that receipt of an interrupt may result
in a context switch, and you don't want to do that while holding
a mutex similarly.

>
Given the privilege to set priority, setting of priority is that
same 1 cycle event that setting or clearing ID would be.

I guess I don't see how that is relevant.  I mean, again, I
suppose you could say, "set the priority mask to infinity to de
facto disable interrupts", but that seems like a distinction
without a difference.

Sometimes you really don't want to be interrupted.

>
And sometimes you don't want to be interrupted unless the
"house is on fire"; I cannot see a time when "the house is
on fire" that you would not want to take the interrupt.
>
Is there one ?!?

Consider a thread that takes a spinlock; suppose some
high-priority interrupt comes in while the thread is holding
that lock.  In response to the interrupt, software decides to
suspend the thread and switch some other thread; that thread
wants to lock the spin lock that the now-descheduled thread is
holding: a classic deadlock scenario.

A valid response here might be, "don't context switch from the
interrupt handler; use a DPC instead".  That may be valid, but
it puts a constraint on the software designer that may be onerus
in practice: suppose the interrupt happens in the scheduler,
while examining a run queue or something.  A DPC object must be
available, etc.

Further, software must now consider the complexity of
potentially interruptable critical sections.  From the
standpoint of reasoning about already-complex concurrency issues
it's simpler to be able to assert that (almost) all interrupt
delivery can be cheaply disabled entirely, save for very
special, specific, scenarios like NMIs.  Potentially switching
away from a thread holding a spinlock sort of defeats the
purpose of a spinlock in the first place, which is a mutex
primitive designed to avoid the overhead of switching.

- Dan C.