search

riscv-software-src / riscv-isa-sim

Spike, a RISC-V ISA Simulator
Other
2.44k stars 855 forks source link

Smdbltrp - VS mode double trap check #1805

Closed lewislzh closed 1 week ago

lewislzh commented 1 month ago

In the double trap check for M-mode in Spike, the current logic transitions directly into a critical error whenever a double trap occurs (i.e., MDT is set) or when a trap happens with nmie being 0. process.cc#L510-L520 It seems that this approach might be slightly too broad, as any exception or interrupt delege to M-mode while nmie is 0 results in a critical error. However, since nmie only controls global interrupt enable, M-mode exceptions that are not double traps should still execute normally. With this in mind, it might be worth considering a revision to line 512 to: if (get_field(s, MSTATUS_MDT) || (interrupt && !nmie)).

aswaterman commented 1 month ago

Smdbltrp is a ratified RISC-V standard, not something we can revise inside Spike. Anyway, the intent of the Smdbltrp extension is that exceptions that occur within an RNMI handler are definitionally "unexpected traps" that cause the processor to enter the critical-error state.

cc @ved-rivos

ved-rivos commented 1 month ago

A RNMI may trap to the RNMI handler if nmie is 1, irrespective of mstatus.MDT being 1 or 0. Further when nmie is 1, unexpected traps in M-mode also trap to the RNMI handler to deliver the double trap. The RNMI trap clears nmie to 0 and all interrupts, including RNMI, are masked when nmie is 0. When the RNMI handler is invoked it is not possible to rely on the polarity of mstatus.MDT to determine whether exceptions that occur in the RNMI handler lead to expected or unexpected traps. Thus the intent of the Smdbltrp extension to treat all traps that occur within an RNMI handler as unexpected traps.

wissygh commented 1 week ago

If processor want to trap to debugmode due to debug interrupt/trigger fire when nmie is 0, should the processor enter the critical-error state? By the way, mepc need not be updated when hart trap to debugmode. @aswaterman @ved-rivos

A RNMI may trap to the RNMI handler if nmie is 1, irrespective of mstatus.MDT being 1 or 0. Further when nmie is 1, unexpected traps in M-mode also trap to the RNMI handler to deliver the double trap. The RNMI trap clears nmie to 0 and all interrupts, including RNMI, are masked when nmie is 0. When the RNMI handler is invoked it is not possible to rely on the polarity of mstatus.MDT to determine whether exceptions that occur in the RNMI handler lead to expected or unexpected traps. Thus the intent of the Smdbltrp extension to treat all traps that occur within an RNMI handler as unexpected traps.

aswaterman commented 1 week ago

Debug interrupts are supposed to be invisible to M-mode (which includes not entering critical error state). The processor should just enter debug mode like normal.

wissygh commented 1 week ago

Debug interrupts are supposed to be invisible to M-mode (which includes not entering critical error state). The processor should just enter debug mode like normal.

Thanks! I got it.

aswaterman commented 1 week ago

Closing as I think there's nothing actionable here, but reopen if there is.