Re: Interrupts in OoO

On Mon, 7 Oct 2024 23:15:39 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Mon, 7 Oct 2024 19:59:59 +0000, Scott Lurndal wrote:
>

Brett <ggtgp@yahoo.com> writes:

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

>

The CPU can give ring 0 priority, it is OoOe after all.

>
I assume you're referring to the Intel 64-bit x86_64 family,
as other processor families don't have a 'ring 0' per se.
>
The AArch64 architecture provides the ability to configure
the two processor interrupt signals to be delivered
independently at any one of three privilege (exception)
levels - kernel, hypervisor or secure monitor.

>
My 66000 provides the ability to configure any number of
interrupts (2^32) through any number of interrupt tables
(2^54) to any number of cores (2^16) at any of the 4
privilege levels and any of the 64 priority levels;

>
While each ARM64 has two interrupt signal

pins*,
                                              they

are driven by the interrupt controller (GIC) which
maps a very large range of interrupts to one of
the two signals and then asserts the signal when
the interrupt is able to be delivered.

Can I ask the latency from a new interrupt arriving
at the GPIC (cycle 1) to when the pin on the core
is asserted by LPIC ??
(*) Even if they are buffered by various PICs and
even if they are not external to the package--
each core has those "pins".
My 66000 does not use pins, but uses a sideband
signaling inside the cache coherence protocol.

Supports a variable range of interrupts up to the
payload size of the MSI-X data payload (32-bits),

How many of those 32-bits are used to denote priority?
How many of those 32-bits are used to denote privilege?
In My 66000's case, no bits from the 32-bit message
are used to denote anything--it is a 32-bit message
from one piece of SW to another piece of SW. Privilege
and Priority are found elsewhere in the interrupt
routing (and I/O translation) structure.

including inter-processor interrupts (SGI),
per-processor interrupts (generated by a core
for itself (e.g. timer interrupts, profiling
interrupts, etc)), wired interrupts (as many
as 2048), peripheral interrupts (2^N (Nmin:16, nMAX:32)
and a complete virtual interrupt space for every
virtual machine.

In My 66000, any process with MMU-granted access
to an interrupt table can send IPIs, and any other
interrupts--just like the core were a device--
even sending interrupts to itself. Just like
device interrupts core interrupts are fire-and-
forget, single instruction events.
All interrupt tables are simultaneously able
to receive new interrupts, hand off pending
interrupts, have enable bits flipped on or off;
and if a new interrupt arrives and the table
is not being watched by any core, the table
manager automatically sends an interrupt to
the next level up so the handler can be scheduled
and process the interrupt. {Table manager is
not a core.}

>
AND it requires no SW PIC updates on world-switches,
and control arrives in an already re-entrant state.

>
That's been true for the ARM GIC forever, except obviously
for interrupts that target a non-resident virtual machine.

See, I got that one solved, too.