search

riscv / riscv-fast-interrupt

Proposal for a RISC-V Core-Local Interrupt Controller (CLIC)
https://jira.riscv.org/browse/RVG-63
Creative Commons Attribution 4.0 International
247 stars 49 forks source link

Automatically clear xintthresh.th #334

Closed hwliu-tommy closed 1 year ago

hwliu-tommy commented 1 year ago

Hi,

I have 2 questions about the auto clear mechanism of xintthresh.th.

If the hart is currently running at some privilege mode x, an MRET or SRET instruction that changes the privilege mode to a mode less privileged than x also sets xintthresh to the lowest supported xintthresh value. This prevents a higher privilege mode from having a non-minimum threshold while a lower privilege mode is running.

If the following sequence happens: (assume interrupt level 0-255 are supported)

This is an abnormal case, because it does not return to the interrupted instruction.
1.  S-mode interrupt taken
2.  S-mode interrupt critical region (set sintthresh.th to 10)
3.  M-mode interrupt taken 
4.  M-mode interrupt critical region (set mintthresh.th to 20)
5.  MRET to U-mode (with *x*=M, clear mintthresh.th)
6.  U-mode program (mintthresh.th=0, sintthresh.th=10)

When MRET changes the privilege to U-mode, only mintthresh.th is cleared. If sintthresh.th is not the lowest level before entering M-mode, it might cause sintthresh.th != 0 in U-mode.

Likewise, if the RISC-V debug specification is implemented and the hart is currently running at some privilege mode x, a DRET instruction that changes the privilege mode to a mode less privileged than x also sets xintthresh to the lowest supported xintthresh value.

A little confuse about the description "current running at some privilege mode x". Because DRET can only be executed in debug mode, but debug mode is not one of the M/H/S/U privilege modes.

Debug Mode is a special processor mode used only when a hart is halted for external debugging. (debug spec section 4.1)

If it means previous privilege mode (dcsr.prv), then it'll encounter a question that this field is also used for keeping the privilege to be returned. So when DRET is executed, it is hard to determine whether the return privilege is less than previous privilege or not, because they share the same CSR field.

Thanks, Tommy

dansmathers commented 1 year ago

question 1) you found a way to have a higher priv mode having a non-minimum threshold while a lower priv mode is running. I can update the text to say "helps avoid" instead of prevent because that is the normal use case. But I see your point that it is possible to write code to get around it but then it is up to software to work around the implications of issue #295. I think we still however want the currently defined behavior. in your example if u-mode then did an ecall back to m-mode and then returned to s-mode, s-mode intthresh.th context is unchanged without m-mode having to remember what the previous sintthresh.th value was.

question 2) we can discuss further in the next TG meeting. maybe that statement should be removed.

hwliu-tommy commented 1 year ago

The answers address all my concerns. Many thanks for your prompt reply.