Does hip.VSTIP revert to defined behavior when menvcfg.STCE=henvcfg.STCE=0? #5
Comments
|
@jscheid-ventana Would you share some words on this question? Thank you. |
|
I suspect so, but I agree that it deserves clarification. Up to @aswaterman or @gfavor , but is the more clear intent presented if the initial qualifying term in the second paragraph was removed, so that it's just:
There are other ways, by adding more terms. |
|
Saying just "When STCE in henvcfg is zero" in the spec would result in defining different arch semantics than the current text. In particular it would create two conflicting arch statements. One that says accesses when menvcfg.STCE=0 raise an illegal instruction exception in non-M modes. And one that says accesses when henvcfg.STCE=0 raise a virtual instruction exception in a subset of non-M modes (i.e VS/VU modes). To the original question: When menvcfg.STCE=0, then henvcfg.STCE is a don't care. Although this doesn't explicitly say what then happens with VSTIP. So the clarification to make in the spec is that when menvcfg.STCE=0 and if the H extension is implemented, then hip.VSTIP also reverts to its defined behavior as if this extension is not implemented. After review and approval by the ARC, this clarification can be incorporated into the rewritten version of the spec that will soon be integrated into the new adoc Priv spec document. |
|
@jscheid-ventana @gfavor Thank you for the detailed clarification. |
|
Ah, right. I was missing the different exception types. This should stay open to track the spec update. |
When menvcfg.STCE=0, mip.STIP reverts to its defined behavior as if unsupporting Sstc extension. When henvcfg.STCE=0, mip.VSTIP reverts to its defined behavior as if unsupporting Sstc extension. [riscvarchive/riscv-time-compare#5] The previous Sstc implementation does not respect the xenvcfg.STCE. In other words, the Sstc may assert mip.STIP (mip.VSTIP) when menvcfg.STCE=0 (henvcfg.STCE=0), which is a misbehaving. This commit presents a proposal that respects the xenvcf.STCE by utilizing the write mask of mip_csr_t::backdoor_write_with_mask() function. If menvcfg.STCE=0 (henvcfg.STCE=0), the corresponding bit of mip.STIP (mip.VSTIP) in the write mask should be 0 to revert the behavior as if unsupporting Sstec extension.
When menvcfg.STCE=0, mip.STIP reverts to its defined behavior as if unsupporting Sstc extension. When henvcfg.STCE=0, mip.VSTIP reverts to its defined behavior as if unsupporting Sstc extension. [riscvarchive/riscv-time-compare#5] The previous Sstc implementation does not respect the xenvcfg.STCE. In other words, the Sstc may assert mip.STIP (mip.VSTIP) when menvcfg.STCE=0 (henvcfg.STCE=0), which is a misbehaving.
The spec says that hip.VSTIP reverts to its defined behavior (as if unsupporting Sstc extension) when menvcfg.STCE=1 and henvcfg.STCE=0.
Does hip.VSTIP reverts to its defined behavior (as if unsupporting Sstc extension) when menvcfg.STCE=henvcfg.STCE=0?
The text was updated successfully, but these errors were encountered: