Re: MSI interrupts

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.

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.

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.

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 ?!?

- Dan C.