Re: MSI interrupts

On Wed, 19 Mar 2025 0:39:04 +0000, Robert Finch wrote:

On 2025-03-18 6:49 p.m., MitchAlsup1 wrote:
<snip>
>
I am not following this. I think there needs to be some way to disable
interrupts that should not be occurring. I think a diagram would help.
+-------+--------+-----+--------+
| fetch | decode | ... | retire |
+-------+--------+-----+--------+
| IRQ^  | ....   | ... | INTDI  |
+-------+--------+-----+--------+
>
These two are happening at the same time.
The INTDI (interrupt disable) should effectively
cause the IRQ to be ignored.
Instructions that are fetched after the IRQ
are relying on interrupts disabled.

a) there is a list of at least 7 places where interrupts can be disabled
..between the device[j] a core[k]
b) what I am addressing is disablement at the core.
c) any yes, I do have a way of disabling interrupts, but is generally
..reserved for nasty things like a system panic.
d) the typical "I'm done with req[k]" needs no interrupt disable.
e) certain architectures can choose to disable interrupts for a short
while
f) others can architect a system that does not need disablement.
Now, back to your ASCII-art::
If there is a interrupt disable instruction (or side effect) in the
pipeline, as seen at DECODE, the disable has already happened, and
the pipeline is just waiting for the event to become manifest. This
is that window of uncertainty.

Suppose there is an interrupt disable instruction in the pipeline that
has not been performed yet

As seen at DECODE it has already happened;
as seen at RETIRE it remains pending.
Different ends of the pipeline are allowed/required to know things
differently.

                          (they are not done until the retire stage in
Q+). So, interrupts are enabled when detected at an earlier pipeline
stage (fetch). It turns out that the interrupt should not have been
fetched from the interrupt queue as interrupts are about to be disabled
by an earlier instruction.

This is that tangled web some weave.

                           I think this matters because of the purpose
of disabling the interrupts. There could be other instructions after the
int disable including yet to be fetched instructions relying on the fact
that interrupts are disabled.

If one bothers to disable core from seeing interrupts in My 66000,
The disable happens in program order, and is made to appear as if in
program order.
Likewise, if one enables core interrupts, the instruction following the
enable can take an interrupt (before it executes).
But you seem to be missing the point--it is possible (and I would argue
beneficial) to architect your interrupts such that interrupt disable is
not necessary >98& of the time. You do it when required, you don't when
you can get away with out it.
Completion interrupts ("I'm done with blah[k]") should not need to DIs.

If the interrupt did not affect other aspects of the instruction being
interrupted (it maybe just sets an interrupt bit in the pipeline
register), I think it might be possible to handle this by having an
interrupt enable flag in the pipeline registers.

If you head in that direction, you need to transfer control to the ISR
at the front of the pipeline, so that a mispredicted branch backs-up
to the 1st instruction in ISR, and then throw the window away with the
normal logic, leaving IP pointing at the branch or branch target.

                                                 That way when the
interrupt is disabled, all the interrupt enable flags in the pipeline
registers could be cleared. When the disabled interrupt reaches retire,
it would have to be logged (queued) so that it can be executed when
interrupts are re-enabled.

It is for all these reason, I counsel you to device a system where the
typical interrupt needs to disable nothing.

It gets worse with branches involved.

Which is why you want greater orthogonality wrt interrupts and IE-bit.