search

riscv / riscv-aia

https://jira.riscv.org/browse/RVG-59
Creative Commons Attribution 4.0 International
81 stars 19 forks source link

Is there any requirement about the speed of arbitration or the interrupt infomation transfer? #82

Closed zhuotianshu closed 5 months ago

zhuotianshu commented 5 months ago

For example:

  1. Is it necessary for the change of the value of topei to be immediately visible on topi? If the answer is no, what if a fence io is executed between reading topei and topi?
  2. Is it mandatory for the value of topi to cause an immediate trap? In other words, if software reads a value of topi that should cause a trap, will HART trap right after the CSR read instruction? Additionally, if the answer is no, what happens if a fence io is executed after reading *topi?
  3. Is it mandatory that after I changed the hstatus.VGEIN, the vstopei should immediately changed to show the interrupt of corresponding guest interrupt file, and hart won't see any interrupt from the last guest interrupt file after the CSRW instruction?
jhauser-us commented 5 months ago

@zhuotianshu:

  1. Except when the specs explicitly say otherwise (which they sometimes do), the effects of changes to CSRs are required to be visible immediately in the next executed instruction, the same as for other ISA registers like x5 and f7. If software executes two CSR reads back-to-back, first from stopei and then from stopi (and if stopei doesn't change in between), then the value seen for stopi must be consistent with the value that was read from stopei one instruction earlier.

    If harware has a physical delay between changes in stopei and effects in stopi, then the hart implementation is required to delay (interlock) the second instruction that reads stopi so software will not see an inconsistent value for stopi.

  2. In the RISC-V Privileged Architecture manual, in Section 3.1.9, "Machine Interrupt Registers (mip and mie)", and in Section 5.1.3, "Supervisor Interrupt Registers (sip and sie)", see this paragraph: "These conditions for an interrupt trap to occur must be evaluated in a bounded amount of time...." This is an example where the spec explicitly allows a visible delay. A FENCE instruction will not help here.

    The Advanced Interrupt Architecture (Smaia/Ssaia) changes some of the conditions for an interrupt trap, but the rule for the bounded amount of time is intended to remain the same.

  3. See answer 1. After hstatus.VGEIN is changed, any effects on the value of vstopei are visible by the next executed instruction. Furthermore, the paragraph referenced in answer 2 says, "These conditions for an interrupt trap to occur must ... be evaluated immediately following the execution of ... an explicit write to a CSR on which these interrupt trap conditions expressly depend...." Since the conditions for an interrupt trap depend on the value of hstatus.VGEIN, my interpretation of this rule is that the trap must be decided and occur, or not occur, immediately after the write to hstatus. A delayed old interrupt from the guest interrupt file selected by the previous value of VGEIN should not happen following the write to hstatus.

zhuotianshu commented 5 months ago

Thank you very much, @jhauser-us. I basically understand your response. I'd like to double-check the applicability of the following sentence:

Except when the specs explicitly say otherwise (which they sometimes do), the effects of changes to CSRs are required to be visible immediately in the next executed instruction.

Does this also apply to indirect accessed CSRs? Should changes to eie/eip immediately affect *topei? Does this also apply to MMIO? Should changes to the ie/ip bits in APLIC immediately affect the topi register of IDC?

jhauser-us commented 5 months ago

Except when the specs explicitly say otherwise (which they sometimes do), the effects of changes to CSRs are required to be visible immediately in the next executed instruction.

Does this also apply to indirect accessed CSRs? Should changes to eie/eip immediately affect *topei?

I believe so, yes. Because extensions Smcsrind/Sscsrind and Smaia/Ssaia do not say anything otherwise, the effects of changing eip or eie in an IMSIC interrupt file should be visible by the next instruction. (To make this be true, execution of the next instruction might be delayed automatically.)

Does this also apply to MMIO? Should changes to the ie/ip bits in APLIC immediately affect the topi register of IDC?

Because the APLIC spec doesn't say anything otherwise, it should be safe to assume that changes to APLIC ip/ie bits will show up "immediately" in the topi register of an IDC structure. (To make this be true, the APLIC could delay a read of a topi register if it immediately follows an access to ip/ie bits. Although realistically, I believe the clock speed for an APLIC and the maximum rate of access to its registers will together likely be slow enough that no extra delay needs to be added.)

zhuotianshu commented 5 months ago

Except when the specs explicitly say otherwise (which they sometimes do), the effects of changes to CSRs are required to be visible immediately in the next executed instruction.

Does this also apply to indirect accessed CSRs? Should changes to eie/eip immediately affect *topei?

I believe so, yes. Because extensions Smcsrind/Sscsrind and Smaia/Ssaia do not say anything otherwise, the effects of changing eip or eie in an IMSIC interrupt file should be visible by the next instruction. (To make this be true, execution of the next instruction might be delayed automatically.)

Does this also apply to MMIO? Should changes to the ie/ip bits in APLIC immediately affect the topi register of IDC?

Because the APLIC spec doesn't say anything otherwise, it should be safe to assume that changes to APLIC ip/ie bits will show up "immediately" in the topi register of an IDC structure. (To make this be true, the APLIC could delay a read of a topi register if it immediately follows an access to ip/ie bits. Although realistically, I believe the clock speed for an APLIC and the maximum rate of access to its registers will together likely be slow enough that no extra delay needs to be added.)

Okay, thanks again!

jhauser-us commented 5 months ago

Although this issue was answered and closed, there is news that the RISC-V Architecture Review Committee is exploring whether there should be a spec change that would change one of the answers. The question was:

Does this also apply to indirect accessed CSRs? Should changes to eie/eip immediately affect *topei?

My answer was:

I believe so, yes. Because extensions Smcsrind/Sscsrind and Smaia/Ssaia do not say anything otherwise, the effects of changing eip or eie in an IMSIC interrupt file should be visible by the next instruction.

The ARC agreed that this answer is correct today, but an explicit arbitrary delay is being considered to be added from the IMSIC for this case.

Even if this change is made to the IMSIC spec, I believe my other answers will remain correct.