Re: MSI interrupts

On Thu, 13 Mar 2025 18:34:32 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Thu, 13 Mar 2025 4:50:47 +0000, Robert Finch wrote:
>

Planning on having the Q+ CPU respond directly to MSI interrupts. My
thought is to integrate an interrupt controller directly into the CPU
which will have several queues to prioritize interrupts. The controller
will take care of detecting the highest priority interrupt to process,
performing priority inversion occasionally, and detect stuck interrupts.

>
My 66000 went all the way to MSI-X interrupts as its base.
>
There are mapping methods to map INTx and INTk into MSI-X messages.
MSI->MSI-X mapping is "just zero extend the message".

>
In both cases, the a 32-bit data payload (the MSIX Vector #) is written
to the MSI-X target address (typically the interrupt controller).
>
The difference between them is
>
  MSI                     MSI-X
  Supports 1 to 32        Supports an unlimited number of
  _contiguous_ data       vectors, each with an unique non-contiguous
  payloads (vector        vector index (data payload) and target
  index).                 address.

Yes, MSI is a strict and degenerate version of MSI-X

With MSI, only the base interrupt number (data payload) is
defined and only one interrupt controller target address is
use used for all vectors. So vector 0 will send the base number, vector
1 will send the base number plus one, etc.
>
With MSI-X each vector has an assigned data payload (vector
number) which do not need to be contiguous or monotonically
increasing.  With MSI-X, each interrupt can have a different
target address (i.e. perhaps a secure interrupt controller
for some, and a non-secure interrupt controller for others)
>
In the ARM case, there are different interrupt types (SGI,
PPI, SPI, LPI) and each one has a different interrupt controller
address that the MSI-X vector address should point to.

In My 66000 case, there is an 8-bit field from the Originating-
Software-Stack (which I/O MMU uses in translation) that prioritize
DMA*, interrupt delivery, page fault delivery, and device error
delivery.
(*) DRAM access in My 66000 uses the priority of the core at the
instant of AGEN to allow higher priority cache miss requests to
percolate through the interconnect faster, and to allow a higher
priority ATOMIC event to actively interfere with a lower priority
ATOMIC event, but not the reverse. The interconnect uses it more
like a virtual channel than a priority.
As to that 8-bit field:: when an interrupt of higher priority than
a core is currently running arrives, core captures the interrupt.
The interrupt message (now 42-bits in size) sets the priority of
the software-stack (2-bits). SW then extracts the 8-bit field
and uses it to dispatch to an interrupt-class service handler
{ISR, Timer, ECC-fail, SVC, SVR, SATA, NVMe, keyboard, mouse, ...}.
At the instant control arrives, the dispatcher is already re-entrant
{able to take a higher priority event even of itself} running at its
priority, under its Root Pointers, and ASIDs, with its pending
exceptions, and register file, with registers R0..4 filled with
exception data union{Instruction, Operand 1..3},...}.

                                                        This
allows the message-based emulation of level sensitive interrupts
by using two vectors, one to assert the interrupt and a second
to deassert the interrupt at the interrupt controller.

I will have to borrow a trick such as this.

So MSI is useless for modern devices and basically deprecated
and cannot be used support level sensitive (e.g. legacy PCI)
interrupts.

That was my view once I ran into MSI-X:: MSI-X is a complete and
more flexible superset of MSI.

>
Most modern devices advertise the MSI-X capability instead.

And why not:: its just a few more flip-flops and almost no more
sequencing logic.