A one-page chapter naming the machinery you met on
the stimecmp page. The base architecture gives
timers to M-mode only (mtime/mtimecmp), so every S-mode timer arm
was an SBI call up to M, where firmware multiplexed all the logical
timers onto its one comparator and reflected expiries back down as
delegated interrupts — two privilege crossings per arm, more for
VS-mode guests (VS → HS → M).
Sstc (“Ss” = supervisor-level, “tc” = timecmp) collapses the ladder to one CSR write:
| Behavior | |
|---|---|
| stimecmp (S-level) | 64-bit comparator: STIP pends while time ≥ stimecmp (unsigned). Full definition in ch. II·12 §12.1.12. |
| vstimecmp (VS-level) | The same facility for guests under the H extension (ch. II·15) — a VM’s timer tick without hypervisor round trips. |
| menvcfg.STCE / henvcfg.STCE | The machine (and hypervisor) opt-in gates. |
Existing S-mode software keeps working either way: an SEE that used to program timers via SBI calls simply implements those calls using stimecmp underneath, while new kernels write the CSR directly.
Hardware Designer Notes
Implementation is a strict subset of what mtimecmp already required: same time bus, one more comparator and pending-bit wire. The win is entirely in software path length — the hottest periodic interrupt in the system stops crossing privilege levels twice per tick.
Minimal Linux-boot hart MUST
- One 64-bit unsigned comparator against the time value per implemented level (S, and VS with H), driving STIP as a level signal
- Honor the STCE gates: when clear, stimecmp accesses raise illegal-instruction (below M) and STIP returns to write-controlled behavior
MAY simplify / trap-and-emulate
- Ship a Linux-bootable core without Sstc (SBI timers via mtimecmp work) — but the comparator is tiny and RVA23 mandates it; there is little reason to omit it
Check yourself — Sstc
1.Without Sstc, what does arming an S-mode timer for a Linux scheduler tick cost?
2.What exactly does the extension add architecturally?