Re: Microarchitectural support for counting

On Fri, 4 Oct 2024 18:11:23 +0000, EricP wrote:

Scott Lurndal wrote:

Brett <ggtgp@yahoo.com> writes:

When a modern CPU takes an interrupt it does not suspend the current
processing, instead it just starts fetching code from the new process
while
letting computations in the pipeline continue to completion.  The OoOe
can
have a 1000 instructions in flight. At some point the resources start
getting dedicated to the new process, and the old process is drained out
or
maybe actually stopped.

>
Not necessarily the case.   For various reasons, entry to the interrupt
handler may actually have a barrier to ensure that outstanding stores
are committed (store buffer drained) before continuing.   This is for
error containment purposes.
>

>
Yes but pipelining interrupts is trickier than that.
>
First there is pipelining the super/user mode change. This requires
fetch
to have a future copy of the mode which is used for instruction address
translation, and a mode flag attached to each instruction or uOp,
each checkpoint saves a mode copy, and retire has the committed mode
copy.
Privileged instructions are checked by decode to ensure their fetch mode
was correct.
>
On interrupt, if the core starts fetching instructions from the handler
and
stuffing them into the instruction queue (ROB) while there are still
instructions in flight, and if those older instructions get a branch
mispredict, then the purge of mispredicted older instructions will also
purge the interrupt handler.

Not necessary, you purge all of the younger instructions from the
thread at retirement, but none of the instructions associated with
the new <interrupt> thread at the front.

                             Also the older instructions might trigger
an exception, delivery of which would take precedence over the delivery
of the interrupt and again purge the handler. Also the older
instructions
might raise the core's interrupt priority, masking the interrupt that
it just tried to accept.
>
The interrupt controller can't complete the hand-off of the interrupt
to a core until it knows that hand-off won't get purged by a mispredict,
exception or priority change. So the hand-off becomes like a two-phase
commit where the controller offers an available core an interrupt,
core accepts it tentatively and starts executing the handler,
and core later either commits or rejects the hand-off.
While the interrupt is in limbo the controller marks it as tentative
but keeps its position in the interrupt queue.
>
This is where your point comes in.
Because the x86/x64 automatically pushes the saved context on the kernel
stack, RIP, RSP, RFLAG, that context store can only happen when the
entry
to the interrupt sequence reaches retire, which means all older
instructions must have retired. At that point the core sends a commit
signal to the interrupt controller and begins its stores, and controller
removes the interrupt from its queue. If anything purges the hand-off
then
core sends a reject signal to controller, which returns the interrupt
to a pending state at its position at the front of its queue.