sail-riscv
sail-riscv copied to clipboard
riscv
Can cycle, instret, time unprivileged CSRs exist in M-mode only implementations?
The cycle, instret and time CSRs are defined to be unprivileged read-only shadows of mcycle, minstret and mtime respectively. Currently the Sail code assumes they exist only if U-mode is implemented: https://github.com/riscv/sail-riscv/blob/master/model/riscv_sys_control.sail#L152
Are M-mode only implementations either permitted or required to implement the shadows? From reading the spec I'm not entirely sure. I'm asking in part because rdcycle, rdinstret and rdtime are defined as instruction aliases for reading them and it would be natural to use them but they won't work in M-mode only implementations at present. There is also an interaction with the access system registers permission on CHERI.
This probably should be asked in riscv-isa-manual mailing list, more than in the Sail maillist, so adding them. It certainly should be clarified there.
On Tue, Nov 1, 2022 at 4:19 AM Robert Norton @.***> wrote:
The cycle, instret and time are defined to be unprivileged read-only shadows of mcycle, minstret and mtime respectively. Currently the Sail code assumes they exist only if U-mode is implemented: https://github.com/riscv/sail-riscv/blob/master/model/riscv_sys_control.sail#L152
Are M-mode only implementations either permitted or required to implement the shadows? From reading the spec I'm not entirely sure. I'm asking in part because rdcycle, rdinstret and rdtime are defined as instruction aliases for reading them and it would be natural to use them but they won't work in M-mode only implementations at present. There is also an interaction with the access system registers permission on CHERI.
— Reply to this email directly, view it on GitHub https://github.com/riscv/sail-riscv/issues/189, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJQWC7INOQSUMAYZXTDWGD4CXANCNFSM6AAAAAART6X3MM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I would hope so, otherwise Clang needs to know what mode it's generating code for to know whether to read cycle or mcycle for __builtin_readcyclecounter. It's not exactly onerous on implementations, either, it doesn't require any new state.
This is a tricky question. If Zicsr is implemented, then Mmode has access to all CSRs defined for the extensions the implementations claims to support.
Zicntr is the extension that defines whether the time, mcycle, and minstret CSRs exist or not, and a valid implementation is to not have them. A profile is likely to require them, though (and also require configurable permission to access them with Zicounteren).
That has no dependence on the support of Umode though. Even if Umode is not implemented, access to the time CSR is supported if Zicntr is supported (since Mmode code has access to all implemented CSRs that are defined for all priv levels). An example of where this is useful is Mmode-only implementation support of FP, which requires that the Umode fscr be implemented.
What makes this tricky is that the Mtime CSR (as opposed to all the others) doesn't exist (it did once upon a time). Mtime is defined to be MMIO accessible using an implementation defined MMIO address
If you want to read the time CSR, you need a shadow HW CSR to be monitoring that MMIO address, or you need to convert the CSR read into an MMIO load.
From any other mode you could trap to Mmode and have the Mmode handler read that MMIO location, but that is problematic here because a CSR that should be accessible because the defining extension is supported (Zicntr) should never take an exception in Mmode.