Smdbltrp - VS mode double trap check

[lewislzh]

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]

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]

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.