On Tue, Dec 1, 2020 at 5:21 PM Allen Baum <allen.baum@...> wrote:

So to know if M-mode can fake an Smode counter interrupt or not,(which it can currently do), 

Mmode SW needs to attempt to write STMECMP and see if it traps? OR attempt to set the STIP bit and see if it sticks? 

You might want some non-normative text about discovery.

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.)

 

IS there some reason for removing the existing behavior of allowing STIP to be writable in MIP?

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