Re: Fast-track "stimecmp / vstimecmp" extension proposal

Ved Shanbhogue

Greg Hi -

Agree with you on what you wrote below.

I have a few comments on on the vstimecmp section of the proposal:

1."When this bit is set, access to the vstimecmp register (if implemented) is permitted in VS-mode." contradicts the privileged specification. To support nested virtualization, accesses to the VS CSRs should cause a virtual instruction exception as noted in section 5.2 of the privileged specification. Perhaps this text should be updated to state "When this bit is set, the vstimecmp substitutes for stimecmp so that instructions that would normally read/write stimecmp would instead access vstimecmp."

2."when the TM bit in the hcounteren register is clear, attempts to access the vstimecmp register while executing in VS-mode will cause a virtual illegal instruction exception if the same bit in mcounteren is 1" is not clear on the type of exception. Is "virtual illegal instruction" intended to be "illegal instruction" or "virtual instruction" exception?  "illegal instruction exception" looks right.

3."whenever (time + htimedelta) contains a value greater than or equal to vstimecmp" - may be a bit ambiguous as "time" when V=1 is already defined to have the htimedelta offset included. Perhaps this could be restated to replace time with mtime so that there is no ambiguity in the definition - "whenever (mtime + htimedelta) contains a value greater than or equal to vstimecmp"

Further, could the proposal be extended to also include the mtimecmp CSR?

- ved

On 9/13/21 7:32 PM, Greg Favor wrote:

On Mon, Sep 13, 2021 at 5:07 PM Phil McCoy <pnm@...> wrote:
> stimecmp is intentionally defined to compare against the time CSR

But time is just a pseudo-alias for the memory-mapped mtime register, right?  Per the privileged ISA spec section 3.1.11 and 3.1.12:
The time CSR is a read-only shadow of the memory-mapped mtime register.

The time CSR is an actual CSR.  It is a "shadow" in the sense that time values in mtime eventually appear in the time CSR.  You can imagine they are always equal, but the architecture allows for there to be a delay between when a value appears in mtime and when it appears in the time CSR.
. . .
Implementations can convert reads of the time and timeh CSRs into loads to the memorymapped
mtime register, or emulate this functionality in M-mode software.

Yes, an implementation can trap accesses to the time CSR and emulate them, or an implementation can convert the CSR accesses to memory reads of the mtime register.  But the time CSR itself is architecturally a CSR within a hart.  Whether actually implemented within the hart, or trapped and emulated, or transparently "emulated" by hardware.
. . .
Because the time counter can be shared between multiple cores, it cannot be inhibited with
the mcountinhibit mechanism.

So, still we have the problem that the stimecmp CSR (which is presumably physically located in the CPU/hart) is being compared against a timer register that is physically located in a separate timer block that is likely to be physically distant from the CPU/hart and in a different clock and power domain.

stimecmp is compared against time, and vstimecmp is compared against (time+htimedelta).  These and time can all be physically implemented in the hart, or they can all be trapped and emulated (in conjunction with suitable hardware outside the hart), or all "emulated" by hardware.  All implementation approaches are accommodated.  While low-end designs may take one of the latter implementation approaches, it is expected that higher end designs will physically implement time within the hart (as is done in most all ARM and x86 designs).  Most of the past proposals from the RV community for Sstc-like functionality have all been for having CSRs and, in one case, also introducing an mtimecmp CSR.



Join to automatically receive all group messages.