search

riscv / riscv-isa-manual

RISC-V Instruction Set Manual
https://riscv.org/
Creative Commons Attribution 4.0 International
3.71k stars 646 forks source link

Suggest parallelism between scounteren and mcounteren behavior #1740

Closed davidharrishmc closed 4 days ago

davidharrishmc commented 4 days ago

There are some odd discrepancies between mcounteren and scounteren.

Per Sections 3.1.11 and 10.1.15, if a hart has no U-mode, “the mcounteren register should not exist” but regardless, “scounteren must be implemented.” Is there a reason for this? Why should a hart with only M mode have scounteren?

According to 3.1.11 regarding mcounteren: “When one of these bits is set, access to the corresponding register is permitted in the next implemented privilege mode (S-mode if implemented, otherwise U-mode).” But according to 10.1.5 "However, U-mode may only access a counter if the corresponding bits in scounteren and mcounteren are both set.” These seem to be contradictory. In a system with only M and U mode, it it necessary to write a 1 to both scounteren and mcounteren, or just to mcounteren?

The spec would make more sense if scounteen is only implemented in a system with S-mode.
Are these quirks a historical oversight due for a correction, or an intentional feature, or a mistake that needs to continue for the sake of compatibility? Is it appropriate to propose the following correction here, or is there a more formal process necessary to prevent breaking systems?

I think the language in 10.1.5 should change from:

"scounteren must be implemented. However, any of the bits may be read-only zero, indicating reads to the corresponding counter will cause an exception when executing in U-mode. Hence, they are effectively WARL fields.”

to

In harts with S-mode, scounteren must be implemented. However, any of the bits may be read-only zero, indicating reads to the corresponding counter will cause an exception when executing in U-mode. Hence, they are effectively WARL fields. In harts without S-mode, the scounteren register should not exist, and mcounteren controls access to counters in U-mode.

or for backward compatibility:

In harts with S-mode, scounteren must be implemented. However, any of the bits may be read-only zero, indicating reads to the corresponding counter will cause an exception when executing in U-mode. Hence, they are effectively WARL fields. In harts without S-mode, the scounteren register is depricated. It may be implemented for backward compatibility with version 20240411 of the privileged spec, and could contain write-only 1s, but preferably does not exist. If scounteren does not exist, mcounteren alone controls access to counters in U-mode.

davidharrishmc commented 4 days ago

Maybe all this is implicit that scounteren does not exist when S-mode is not supported, but the "scounteren must be implemented" language seems strong.

gfavor commented 4 days ago

The "scounteren must be implemented" requirement is in the Ss1p13 extension (the Supervisor-Level ISA chapter). If you have an M-mode-only design, then you aren't implementing Ss1p13 and the Supervisor-Level ISA, and hence that requirement is not applicable.