Re: MSI interrupts

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.
Suppose there is an interrupt disable instruction in the pipeline that has not been performed yet (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. 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 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. 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 gets worse with branches involved.