virtualizing scountovf

[senlinhe]

Does it mean scountovf cannot be read from VS-mode or VU-mode?

[allenjbaum]

This sounds fairly direct:
H-extension is necessary for VU or VS mode to exist at all
Sscofpmf is necessary for scountovf to exist
If menvcfg.CDE=1, then Smcdeleg/Ssccfg extensions are enabled

So yes, countovf cannot be (directly) read from VS-mode or VU-mode if menvcfg.CDE=1.
The M- or HS-mode trap handler can decide to emulate, or not, which will make it appear to be read.

[senlinhe]

does it mean "Smcdeleg" override "Sccofpmf" ?
according to "Sccofpmf", the scountovf should be readable.

So, to be clear, I should ask does this mean scountovf is unreadable from VS or VU mode, irrespective of menvcfg.CDE

[allenjbaum]

Hmm - that sounds like a spec bug, because it is pretty clear from spec section 9.3 that it will trap with a virtual-instruction exception - there is no ambiguity. @jhauser-us - would you like to chime in?

[gfavor]

The *envcfg.CDE bits take priority since the spec says "When CDE=0, the Smcdeleg and Ssccfg extensions appear to be not implemented."

So if CDE=0, then Smcdeleg effectively does not exist. And when CDE=1, then the first post #2287 (comment) applies.

[allenjbaum]

/Gadfly mode on/
The problem here is that there are 3 widely separated "normative" statements that need to be combined to reach your conclusion:
Sec20.2 says:
In VS mode, scountovf bit X is readable when both mcounteren bit X and hcounteren bit X are set; otherwise reads as zero.
(no) mention being conditional on menvcfg.CDE at all, nor being conditional on Smcdeleg and Ssccfg.
Section 9.3 says
For implementations that support Smcdeleg/Ssccfg, Sscofpmf, and the H extension, whenmenvcfg.CDE=1,
attempts to read scountovf from VS-mode or VU-mode raise a virtual-instruction. exception.
Section 9 says
extension Smcdeleg .... encompasses all added CSRs and all behavior modifications for a hart, over all privilege levels.

Sec 20.2 and section 9.3 contradict each other for some values of the mentioned states.
And the admonition that it encompasses "all behavior modifications for a hart" is less than obvious, but can be reasoned to imply that 9.3 takes precedence over 20.2. That is...less than obvious ... without a rather careful reading of the spec, and memorizing/understanding what happened 11 sections earlier.
Your explanation needs that section 9 reference, otherwise I don't think your explanation makes sense.
It will be extremely difficult for certification/architecture tests (or UDB) to be able to put those 3 statements together to come up with tests - much less prevent ISA manual issues from designers from taking up your time to come up with the reasoning.
I am confident that we will get certification waiver requests and appeals when implementers get it wrong and claim that the spec allows behaviors that we say are incorrect (for a very careful reading of the spec).

I've had this discussion with Andrew, who admits that new extensions often don't modify existing text in the spec, and readers simply have to know that newer specs take precedence over older specs (without any easy way to determining which sections are newer or which sections are specifically affected) - and that is it too much work to update (existing) specs to make the linkages obvious.

I accepted that it would be work to scour through the exiting spec and fix this, but disagree that leaving it unfixed when issues get raised is acceptable. It is more work to have to answer questions like this than get it right the first time. For "legacy" extensions, I think it is quite a bit less work to whack-a-mole (when the issue does come up) fix it than to leave it unfixed.

For that reason I would suggest that sec 20.2 be modified with an explicit reference "subject to sec 9.3" which should clear this issue up for the future- you won't have to explain this again. That's a pretty simple fix.

And I'll probably argue about this for every ISA manual issue that comes up that can be fixed so easily.

/Gadfly mode off/