RISC-V Design · All levels
Privileged Architecture: Tricky Q&A
Senior interview and review questions for Privileged Architecture.
Section Q&A bank
Use these drills after completing all topics in Privileged Architecture. Answer with workload framing, mechanism proof, owner, and release decision.
Why is trap delegation not equivalent to giving S-mode full control of all exceptions and interrupts?
diagram
[INT][RISCV][PRIVILEGED-ARCHITECTURE]
Q: Why is trap delegation not equivalent to giving S-mode full control of all exceptions and interrupts?
A:
Delegation is selective and still bounded by machine-mode policy. medeleg and mideleg bits choose which causes are handled in S-mode, but non-delegated causes always trap to M-mode, and machine-level controls still gate interrupt routing, timer exposure, and platform services. Secure systems deliberately keep critical faults and platform ownership in M-mode so S-mode can manage the OS without becoming a root-of-trust substitute.
FOLLOW-UP TRAP: Assuming enabling delegation means M-mode is no longer part of the control path.What makes an exception precise in an aggressively pipelined RISC-V core?
diagram
[INT][RISCV][PRIVILEGED-ARCHITECTURE]
Q: What makes an exception precise in an aggressively pipelined RISC-V core?
A:
Precision means all older instructions are architecturally committed, the faulting instruction is reported exactly once with correct context, and no younger instruction has modified visible state. Achieving this requires ordered retirement bookkeeping, replay-safe side-effect control, and deterministic trap-state capture even when speculative execution is deep. If younger memory writes or CSR side effects escape before fault handling, software sees irreproducible behavior and recovery becomes unsafe.
FOLLOW-UP TRAP: Treating precise exceptions as only a decode-stage property rather than a retire-stage guarantee.Why do timer interrupts often show jitter even when mtimecmp is programmed correctly?
diagram
[INT][RISCV][PRIVILEGED-ARCHITECTURE]
Q: Why do timer interrupts often show jitter even when mtimecmp is programmed correctly?
A:
Observed jitter combines timer source granularity, interrupt synchronization latency, masking windows, and trap-entry overhead under contention. Even with correct compare values, software can miss ideal boundaries if compare updates race with pending interrupts, if clock-domain crossings are slow, or if higher-priority traps delay service. Reliable designs characterize and budget each component instead of attributing timing variance only to software scheduler behavior.
FOLLOW-UP TRAP: Blaming jitter solely on OS code without validating hardware timer/interrupt path latency.Why is sfence.vma required after page-table updates when the PTE memory write already completed?
diagram
[INT][RISCV][PRIVILEGED-ARCHITECTURE]
Q: Why is sfence.vma required after page-table updates when the PTE memory write already completed?
A:
A completed store updates memory, but harts may still hold old translations and permissions in TLBs or page-walk caches. sfence.vma is the architectural synchronization point that invalidates stale translation state so subsequent accesses observe new mappings consistently. Without it, software can see mixed old/new permissions across cores, causing intermittent faults or security holes that are hard to reproduce.
FOLLOW-UP TRAP: Assuming memory coherence for PTE data automatically guarantees coherent translation state.