[PATCH v1 2/2] lib: sbi: Implement Sstc extension

[Jessica Clarke]

[Resending as plain text for the OpenSBI list, and fixing a typo]

On 6 Mar 2022, at 16:28, Greg Favor <gfavor at ventanamicro.com> wrote:
> 
> On Sun, Mar 6, 2022 at 8:13 AM Jessica Clarke <jrtc27 at jrtc27.com> wrote:
>> That’s not the question. The question is how an architectural extension can remove an explicitly specified feature from the base privileged spec that all software stacks ({BBL, OpenSBI} x {FreeBSD, Linux, others}) running on Unix-class hardware rely on, thereby making priv+Sstc explicitly backwards incompatible with base priv. Ratified specifications are supposed to provide a compatibility guarantee, and extensions are supposed to add not remove (except where it’s removing choice).
> 
> As to why Sstc couldn't have instead "added" to the STIP definition by OR'ing in a new interrupt signal with the existing writable CSR bit, that was decided by Andrew and John (and ultimately the AR Committee).  I don't remember off-hand the architectural problem with simply doing that, but they were clear at the time about that being a problem (and it made sense to me at the time as well).  Which then led to the current specification.
> 
> Also note that backward compatibility is provided through the *envcfg.STCE bits.  The same backward compatibility issue exists for the Svpbmt extension - which leads to having the *envcfg PBMTE bits.  This was one of the reasons for creation of the *envcfg CSRs.

That works for Svpbmt where S-mode is the only thing responsible, but for Sstc the interaction between M-mode and S-mode means that’s not enough. STCE is an M-mode bit, so either you have firmware that never exposes Sstc to S-mode and keeps using mip.STIP, rendering Sstc useless, or you have firmware that always exposes Sstc to S-mode but then has no clue if S-mode is using it or not, meaning it has to assume that S-mode has control of stimecmp and thus it cannot be used by M-mode for SBI calls (since the SBI spec only states a0 and sometimes a1 as being clobbered, with the exception of sepc/scause/stval in the case of faults for some of the legacy SBI 0.1 calls that require dereferencing S-mode-provided pointers).

And the “OR’ing in [an] interrupt signal with the […] writable CSR bit” behaviour already exists for SEIP and, if such a platform-specific method exists, SSIP, so STIP is now inconsistent with the other two core S-mode interrupt sources (i.e. excluding Sscofpmf).

Jess