Re: MSI interrupts

On 2025-03-18 2:51 p.m., EricP wrote:

Robert Finch wrote:

On 2025-03-17 2:33 p.m., EricP wrote:

>
Another problem is what does the core do with the in flight instructions.
>
>
Method 2 pipelines the switch by injecting the interrupt request at Fetch.
Decode converts the request to a special uOp that travels down the IQ
to Retire and allows all the older work to complete.
This is more complex as it requires a two phase hand-off from the
Interrupt Control Unit (ICU) to the core as a branch mispredict in the
in flight instructions might cause a tentative interrupt acceptance to later
be withdrawn.

>
Oh my, I forgot.
Method 2 will be used as it is desired to able to insert either an instruction at the fetch stage or a vector address.

>
The ICU believes the core is in a state to accept a higher priority
interrupt. It sends a request to core, which checks its current state and
sends back an immediate INT_ACK if _might_ accept and stalls Fetch, or a NAK.
When the special uOp reaches Retire, it sends a signal to Fetch which
then sends an INT_ACCEPT signal to ICU to complete the handoff.
If a branch mispredict occurs that causes interrupts to be disabled,
then Fetch sends an INT_REJECT to ICU, and unstalls its fetching.
(Yes that is not optimal - make it work first, make it work well second.)
>
This also raises a question about what the ICU is doing during this
long latency handoff. One wouldn't want ICU to sit idle so it might
have to manage the handoff of multiple interrupts to multiple cores
at the same time, each as its own little state machine.
>
One should see that this decision on how the core handles the
handoff has a large impact on the design complexity of the ICU.
>
Personally, I would use method 1 first to get something working
then if this is OoO think about getting fancy with method 2.
>
>

Would it not be rare for this to occur? If so, I think the pipeline could just be flushed from the int disabling instruction on. Then the interrupted address recorded as the int disabling instruction. <- this requires identification of an int disabling instruction though. It might just be a store to a specific I/O address, therefore a special store opcode to make it easy to detect?

 It likely is rare but the possibility that the existing instructions,
a branch mispredict or an exception throw, could retroactively change
the state of the interrupt enable flag to disabled creates this
Window of Uncertainty (WoU) that is the length of the pipeline.
 Unless one can find a way to make WoU go away the ICU needs to deal
with the possibility that there could be hundreds of clocks between
when ICU asks a core if it can accept an interrupt and when the core does.
 I had a few ideas walking in the park yesterday. I had been assuming that
when an exception is delivered that it would also automatically disable
interrupts. That may not be a good idea as it means that any instruction
that can throw an exception could cause this retroactive disabling.
 If I remove that exception side effect then the only things that can
manipulate the core's master Interrupt Enable flag are the enable INTEN
and disable INTDI instructions, and the actual delivery of an interrupt.
And those three things can be tracked with a counter in Decode as they
move down the pipeline to Retire. If the counter >0 then there is a
flag change in flight and we don't accept a new interrupt. When count == 0
and Interrupt Enable flag == 1 then core accepts interrupts, which are
injected at Decode and cause a light weight purge of the Fetch buffer.
 

Seems like it could work. There are difficulties using counters with the Q+ ISA as multiple interrupt enable bits could be manipulated at the same time. One interrupt may be enabled and another one disabled by the same instruction.
I am going for a simple approach. Since the CSR instruction is used to manipulate the interrupt enable bits in the status register, if there is any CSR instruction in the pipeline, then interrupts will be masked off until the CSR clears. One issue with this type of approach is evil software could issue a lot of CSRs preventing interrupt servicing from happening. I Could fine tune the decode to sort out CSRs just affecting the interrupt flags. It always seems to be more logic.

Another pipeline issue is Privileged Control Register (PCR) reads and writes.
PCR's don't behave like general registers in that they are not renamed,
and in general operations cannot be replayed or performed out of order.
They behave more like atomic stores that must be performed at Retire
and must not be bypassed by any memory and other PCR ops. (This is why
many of the x86/x64 MSR ops are serialized with a pipeline drain.)
 This affects what it can do with PCR inside the WoU if it causes a state
change that cannot be undone, for example, reading the interrupt data FIFO.