A one-page chapter naming the extension whose machinery you’ve already met: mstatus.MDT (ch. II·3, §3.1.6.2) turns the worst-case failure — a trap striking M-mode before the handler saved its state — from silent corruption into a defined escalation ladder:
- RNMI handler, when Smrnmi is implemented and
mnstatus.NMIE = 1: mnepc/mncause receive what the double trap would have written to mepc/mcause — resumable diagnosis. - Critical-error state otherwise (or when the double trap strikes inside the RNMI handler): execution ceases with architectural state untouched, all interrupts (NMIs included) disabled, and a critical-error signal asserted to the platform — which may restart the hart, the platform, or anything else it deems fit.
- Debug Mode entry as an alternative to the critical-error signal, for bench diagnosis of harts in the critical error state (per the Debug specification).
The recap of the MDT protocol: reset leaves MDT=1; every trap into M sets it; MRET/SRET-in-M clear it; writing MDT=1 clears MIE; RNMI traps neither count as unexpected nor set MDT.
Hardware Designer Notes
For a Linux-class core, Smdbltrp is cheap insurance once Smrnmi exists: the MDT flop and escalation mux are a few dozen gates, and firmware gains a guaranteed-sane failure mode for its most fragile code path.
Minimal Linux-boot hart MUST
- Nothing beyond the p03 MDT implementation — this chapter adds the name, the Smrnmi interlock, and the debug hook
MAY simplify / trap-and-emulate
- Route the critical-error state to your debug module instead of (or before) the platform signal
Check yourself — double trap
1.Rank the escalation ladder when a trap hits M-mode with mstatus.MDT already set.
2.Why does the critical-error state deliberately preserve architectural state (no pc/CSR updates)?