This text takes the same approach as much of the rest of the Supervisor chapter in the Priv spec, i.e. the existing and coming new discovery methods apply equally to these new CSRs as to all existing and new s*/h*/vs* CSRs that may be accessible in S/HS modes.  This extension doesn't try to establish anything different.  Or, put differently, the discovery issue is a general issue (for which this extension does not represent any form of special case).

Whether for this Zstc extension or the coming (for example) Zsn and Zsa extensions, there is trapping behavior as one (ugly) form of discovery method.  And then there will be the new discovery method being developed by tech-config which will be the more reasonable way to discover many things about optional extensions, and optional or WARL features within extensions.

So any new non-normative text about CSR discovery really should be added to the Priv/Unpriv specs as a general matter (separate from this and other in-progress Supervisor extensions).  (And each extension innovating its own "better" discovery method would be an undesirable way to go.)

 

Yes.  This was first pointed out by John, and Andrew and I agreed.  The gist is that when a hart implements stimecmp, for consistency we should require STIP to be read-only - just like MTIP.  (Especially since there is no longer a need for a software-writable bit behind STIP when stimecmp exists.)

Greg