RISC-V Counter Reads: Separate CSR Availability from Privilege Permission
A profiling routine reads cycle successfully in machine firmware but traps in a user task. Another build reads the same CSR without a trap, yet its value does not advance. These observations point to different controls and should not be repaired by changing the same bit indiscriminately.
First establish that the counter is implemented, then distinguish permission to read it from permission for the underlying counter to increment.
Counter instructions do not guarantee counter availability
The Zicntr specification defines the cycle, time and instructions-retired counters and depends on Zicsr. Having CSR instructions does not imply that every counter or optional performance-monitoring facility is available.
rdcycle, rdtime and rdinstret are read-only CSR pseudoinstructions. Their assembler acceptance establishes an encoding, not the privilege policy installed by firmware. Execution environments may intentionally prohibit counter access, including for timing-side-channel reasons.
Preserve the trap cause and faulting instruction. Do not reinterpret every illegal-instruction trap as a missing arithmetic extension or silently substitute a zero timestamp that later appears to be a valid measurement.
Lower-mode access depends on a permission chain
The Machine-Level ISA counter controls use mcounteren to control availability below M-mode. CY, TM and IR correspond to cycle, time and instructions-retired access. A cleared corresponding bit causes a lower-mode read to raise an illegal-instruction exception.
Where S-mode is implemented, granting access at that level does not alone authorize a user task. The Supervisor-Level ISA scounteren rules require both the machine and supervisor permission bits for U-mode access. A writable supervisor bit does not prove that machine firmware has permitted the same counter.
For a hypothetical user-mode cycle read, mcounteren.CY=1 and scounteren.CY=0 still deny access. Setting only the supervisor bit while the machine bit is zero also fails. Inspect actual legal readback; these fields can be read-only zero.
Inhibit changes counting, not accessibility
mcountinhibit serves another purpose. Setting its CY, IR or applicable HPM bit stops the corresponding counter from incrementing. It does not revoke read permission. Conversely, clearing a bit in mcounteren restricts access without stopping the underlying counter.
A successfully read but stationary cycle counter therefore calls for investigating inhibition and execution-environment behavior, rather than assuming that user access was denied. A trap calls for an availability or permission investigation before any interpretation of a counter delta.
There is no time-inhibit counterpart in this mechanism: the memory-mapped mtime counter is not stopped by mcountinhibit. Also, implementations can share mcycle across harts on a core, in which case the CY inhibit field is shared too. A profiling change intended for one hart can affect another observer.
Select a quantity whose meaning matches the measurement
Cycle and time are not interchangeable units. The Zicntr text makes cycle rate dependent on implementation and operating environment, while time measures real-time ticks with an environment-supplied period. Instructions retired is another quantity again; an instruction causing a synchronous exception, such as ECALL, is not counted as retired by this definition.
A proposed permission test records the exact counter, execution mode and applicable enable chain. A separate progression test checks inhibition and the environment's counting policy. Only after those conditions are understood should software interpret deltas or convert them into elapsed time.
RV32 also needs a consistent read of the counter's separate halves, but that does not solve a permission trap or an inhibited source. No CSR reads, permission changes or timing measurements were performed here.
