riscv-isa-manual
riscv-isa-manual copied to clipboard
riscv
Missing CSR address for `mtime`
Chapter 3 , Section 3.2.1 defines that a mtime register should be present, but the CSR address for this register isn't present anywhere in the spec.
The address was present in the spec for v1.7(In the CSR Listing table), but it seems to have been removed. Is the address for this register user-defined now, or am I misreading something?
It isn't a CSR. It's a memory-mapped register (whose address is platform-dependent).
@ObiWanRohan
Btw, there is a time CSR (or two CSRs time and timeh on rv32, respectively):
The time CSR is a read-only shadow of the memory-mapped mtime register. [3.1.11 Machine Counter-Enable Register (mcounteren)]
There is still a mention regarding mtime in section 3.1.11, what is the bit TM of mcounteren supposed to do since mtime is outside the hart ? ignore timer interrupts ?
There is still a mention regarding mtime in section 3.1.10, what is the bit TM of mcounteren supposed to do since mtime is outside the hart ? ignore timer interrupts?
Doesn't the priv spec clearly specify what the TM bit does (which is orthogonal to the fact that mtime comes from outside a hart and that the CSR in question is the 'time' CSR - which is a typically delayed version of mtime) when it says the following?
*When the TM bit in the mcounteren register is clear, attempts to read the time register while executing in S-mode or U-mode will cause an illegal instruction exception. When one of these bits **[TM] *is set, access to the corresponding register [time] is permitted in the next implemented privilege mode (S-mode if implemented, otherwise U-mode).
Btw, you also appear to be looking at a not-latest version of the Priv spec (not that that matters for this question).
Greg
I get what it does, I don't understand what prevents S-mode from accessing mtime directly since it's memory mapped, this mostly seems as a way to trap-and-emulate accesses to time on M-mode, it's not really about accessibility as the previous paragraph mentions ("The settings in this register only control accessibility") since mtime, the source of time (unless blocked by PMP for example) is still accessible.
Well, the OS level might not know the address (since it is intended to be Mmode accessible only), but blocked by PMP or some priv level sensitive PMA is the only other option.
On Mon, May 1, 2023 at 4:27 PM Nick Kossifidis @.***> wrote:
I get what it does, I don't understand what prevents S-mode from accessing mtime directly since it's memory mapped, this mostly seems as a way to trap-and-emulate accesses to time on M-mode, it's not really about accessibility as the first paragraph mentions ("The settings in this register only control accessibility") since mtime, the source of time (unless blocked by PMP for example) is still accessible.
— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/883#issuecomment-1530557996, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJWF4X33NXH7PS7AVULXEBBHRANCNFSM56UY4QCA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I get what it does, I don't understand what prevents S-mode from accessing mtime directly since it's memory mapped, this mostly seems as a way to trap-and-emulate accesses to time on M-mode, it's not really about accessibility as the first paragraph mentions ("The settings in this register only control accessibility") since mtime, the source of time (unless blocked by PMP for example) is still accessible.
'mtime', as a memory-mapped register, is just like all other memory-mapped registers that M-mode wants to prevent lower modes from having access to, i.e. M-mode uses PMPs to restrict access to mtime and all other such MMRs.