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

[Jessica Clarke]

On 6 Mar 2022, at 16:08, Greg Favor <gfavor at ventanamicro.com> wrote:
> 
> On Sat, Mar 5, 2022 at 3:04 PM Atish Patra <atishp at atishpatra.org> wrote:
> > The Sstc spec also made STIP bit in mip as read only. Here is exact
> > snippet from the spec
> > 
> > "If the stimecmp (supervisor-mode timer compare) register is implemented,
> > STIP is read-only in mip and reflects the supervisor-level timer
> > interrupt signal resulting from
> > stimecmp."
> > 
> > Thus, M-mode can't update the STIP bit if sstc is enabled.
> 
> This directly contradicts text from ratified privileged specs (quoting
> Volume 2, Privileged Spec v. 20211203, the current version linked from
> riscv.org):
> 
> +Greg who may shed some light behind the reasoning for this sstc requirement. 
> 
> The proper way to interpret Sstc or any new arch extension that modifies existing arch functionality, is simply that the new extension modifies or overrides the existing functionality.  As new arch extensions get integrated into the same document as existing documents (for which there is a lot of outstanding integration work for both the Unpriv and Priv documents, mixed in with all the work to convert all that stuff to adoc), that will be more readily apparent in one document and, as appropriate, existing ratified architecture text will be modified (aka "clarified") to include forward reference to being modified by an optional arch extension.  The H extension is a big example of modifying (as well as adding to) the pre-existing architecture.  If one doesn't support the H extension, then one can read the existing M and S chapters as is.  But if one does support the H extension, then they and the H chapter need to be read and comprehended together since the pre-existing arch text doesn't directly incorporate all the modifications (as, of course, conditional modifications).


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

Jess