toggle quoted messageShow quoted text
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
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
On 9/13/21 7:32 PM, Greg Favor wrote:
On Mon, Sep 13, 2021 at 5:07 PM Phil McCoy <pnm@...
> 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
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