The timing issue regarding reading *topei

[yichanfeng]

The timing issue regarding reading *topei

[jhauser-us]

Your example is correct. A read of a *topi or *topei CSR always returns the most recent information available.

[jhauser-us]

@yichanfeng, I do not understand the scenario you describe. Software doesn't know what the external interrupt is until it reads *topei (which it should also write at the same time to claim the interrupt). Only by reading *topei does software learn the priority of the interrupt. So, what is this?:

If a hart asks IMSIC for the interrupt arbitration, leading a trap handler to a lower priority interrupt handling (e.g. IID=4)

I don't recognize that step, which you say precedes reading *topei to claim the interrupt.

[yichanfeng]

@jhauser-us
Thanks for your reply.

Yes, SW doesn't know what the external interrupt is until it reads *topei.

I am asking if HW needs to retain the older value of non-zero *topei until SW reads its value in the trap handler when the following scenario occurs.

1. In the machine-level interrupt file of IMSIC, interrupt 4 (ID = 4) is pending-and-enabled. Then, the hart receives the external
   interrupt and traps to M-mode.
2. Before SW executes the CSR instruction to read mtopei in the trap handler, the interrupt 1 (ID = 1, has higher priority) of
   machine-level interrupt file becomes pending-and-enabled due to an MSI write.
3. When SW executes the CSR instruction in the trap handler,
   the read value of mtopei will be 0x10001 (ID = 1, Prio = 1) instead of 0x4004 (ID = 4, Prio = 4).
   => Does this result match expectation (always return the latest value) ?

[yichanfeng]

@jhauser-us

Thanks for your reply.

[umcann123]

Hi @jhauser-us! I also have a question about *topei. What should the expected or suggested behavior be when we read/write the *topei while eidelivery=0? Should it assume that there are no valid external interrupts when eidelivery=0, causing the IMSIC to ignore the *topei access and only read it as 0? Or should it retain its original behavior, allowing harts to read/write the *topei, clean the highest priority eip pending bit, and only prevent the *EIP from being sent to harts?

[jhauser-us]

An interrupt file's eidelivery register has no effect on a *topei register. See new issues #56 and #57.

Note the similarity also with what the AIA spec says about the *topi CSRs:

The value of mtopi is not affected by the global interrupt enable MIE in CSR mstatus.

The value of stopi is not affected by the global interrupt enable SIE in CSR sstatus.

[umcann123]

@jhauser-us Thanks!