Re: MSI interrupts

On Sun, 16 Mar 2025 21:35:29 +0000, Robert Finch wrote:

On 2025-03-15 6:28 p.m., MitchAlsup1 wrote:

On Sat, 15 Mar 2025 20:46:41 +0000, Robert Finch wrote:
>

On 2025-03-15 1:46 p.m., MitchAlsup1 wrote:

On Sat, 15 Mar 2025 2:10:48 +0000, Robert Finch wrote:

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

The SoC system is limited to 64 CPU cores by the use of a 6-bit core
number. So, a 64-bit vector containing which cores to send the interrupt
to could be used. A find-first-one responding could be used to mask
things so that only one CPU sees the interrupt.

>
Consider that you have a pool of 4 cores setup to receive interrupts.
That those 4 cores are running at differing priorities and the interrupt
is at a still different priority. You want the core operating at the
lowest
priority (with the right software stack) to accept the interrupt !!

>
Okay, I wrote a naive hardware filter for this which should work okay
for small numbers of CPUs but does not scale up very well.
What happens if there is no core ready? Place the IRQ back into the
queue (regenerate the IRQ as an IRQ miss IRQ)? Or just wait for an
available core. I do not like the idea of waiting as it could stall the
system.

I can't talk about this for another week or so.

To identify the CPU pool, with a max of 63 CPU per interrupt controller,

Terminology:: My 66000 has 1 interrupt controller (per chip) that can
process MSI-X messages for an unbounded number of interrupt tables and
an unbounded number of cores. Each interrupt table is associated with a
Guest OS (VM) or HyprrVisor (VMM) or ...
The only limitation is the size of the interrupt aperture--
OH, and BTW, I use the word aperture rather than range as the range
may be sparse with unbounded number of holes of unbounded length in
the range {begin..end}. And the service port only services things
in the aperture not in necessarily the range.

the pool could be represented directly as a 64-bit word in the interrupt
vector table. I have been thinking of using a 256-bit vector entry
instead of 128-bits. I allocated 96-bit for an instruction / address
field.

I think you are drifting towards "affinity" (and a flat version of that
itself). Not a wrong way to go, but fraught with peril.
You might be better off heading into a vector of 64-bit containers
which specify participation in one or more affinity groups per core.