Re: MSI interrupts

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".
The Interrupt port lives in the memory controller and takes an
aperture of addresses and maps them to various interrupt tables.
There is a broadcast mechanism that notifies cores of new higher
priority level interrupts pending, and a protocol for getting
an interrupt and notifying the IC that it will be handled by a
core.
Along with the 32-bit message, the architecture provides for
6-bits of priority, 2-bits of SW-stack indexing, and an 8-bit
ISR handler index number.
Interrupt tables remain active even when the virtual machine
it inactive. When next scheduled, priority ISRs will be serviced
prior to low priority thread instructions.
{And some things I can't talk about}

Setting up an MSI interrupt protocol for Q+.
>
The controller will sit on the CPU's main response collect bus.
Interrupt messages contain the interrupter's bus/device/function + a
cause code. They may also contain a target core number.
>
Planning on distributing the interrupt control to peripheral devices
instead of having a system level interrupt controller.