Re: MSI interrupts

On Wed, 19 Mar 2025 13:49:54 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Tue, 18 Mar 2025 21:59:51 +0000, Robert Finch wrote:
>

On 2025-03-18 2:51 p.m., EricP wrote:

----------------

>

Seems like it could work. There are difficulties using counters with the
Q+ ISA as multiple interrupt enable bits could be manipulated at the
same time. One interrupt may be enabled and another one disabled by the
same instruction.

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

>
Because sometimes you need to.  For example, when making a configuration
change to the device, you'll want to disable interrupts that may be
generated as a result of the configuration change (e.g. when flushing
a FIFO on the device, you may not want the 'FIFO Empty' interrupt
to be asserted).

The above is more quickly performed by raising the priority level above
those of interrupts a device may send.
{{This is part of my whole point--one can use priority as if it were
enable/disable, and once you get priority setup as you perform inter-
rupt control transfer, you no longer need DI or EI.}}

Granted, there might be an enable gate on the device itself

As illustrated before, there are at least 7 gates between device and
a core.

that can be used for that, but generally speaking there are other cases
where it will make sense to disable delivery at the interrupt controller
or core (the later, particularly, during certain critical sections).
>

>
When running at any privilege, do you not want to accept an interrupt
at higher priority with as little delay as possible ??

>
Not while the core is executing an OS/hypervisor/device driver critical
section sensitive to interrupts.