The supervisor-level sibling of Smdbltrp, and another one-page naming chapter: every mechanism was defined where the state lives. The ladder extends downward — each level’s double trap is caught one level up:
| Mechanism | |
|---|---|
| VS-mode double trap → HS | henvcfg.DTE enables vsstatus.SDT; the second trap becomes a guest double-trap the hypervisor handles — it can invoke a critical-error handler inside the VM. |
| S/HS-mode double trap → M | menvcfg.DTE enables sstatus.SDT; trap-with-SDT-set delivers cause 16 to M with mtval2 = the would-be cause. M typically raises the OS’s critical-error path via SBI Supervisor Software Events. |
| M-mode double trap → RNMI / critical-error state | That’s Smdbltrp + mstatus.MDT (ch. II·10) — the top of the ladder has no one to catch it, so it escalates to the platform. |
The SDT protocol itself — set on trap entry to S, the write-1-clears- SIE interlock, SRET clearing it, the mcause=16/mtval2 delivery — is on the sstatus page, and the DTE gate bits are on the menvcfg and henvcfg pages.
Hardware Designer Notes
Ssdbltrp turns the kernel’s most confusing failure — a trap inside the trap prologue — into a clean upcall. The hardware is a couple of AND gates on the trap-target logic; the payoff is entirely in debuggability of early-boot and stack-overflow bugs.
Minimal Linux-boot hart MUST
- Nothing new beyond the sstatus.SDT / vsstatus.SDT fields and DTE gates already implemented with p12/p15 — plus routing cause-16 delivery to M (or HS for the VS case) with the mtval2 write
MAY simplify / trap-and-emulate
- Omit it (DTE hardwired 0) on a first Linux boot; firmware then simply cannot distinguish a kernel double fault from a hang
Check yourself — Ssdbltrp
1.S-mode takes a trap while sstatus.SDT is already 1. What happens?
2.Why does writing SDT=1 forcibly clear SIE in the same write?