Platform specs and M/S/U levels of requirements


Greg Favor
 

Yesterday the Arch Review committee (including most notably Krste and Andrew) discussed the issue raised over the past week and in Monday's Platforms group meeting - as part of a more general discussion about the expected structuring of ISA profiles and platforms.  I was asked to write up and convey the results.

First, for context, just like there are multiple RISC-V ISA profiles, there will be multiple RISC-V platforms.  Taking for example the RVA22 profile, this is actually three distinct profiles representing M, S, and U functionality.  One can choose to be compliant with one, two, or all three RVA22 profiles.  Similar is true for all the other profiles.

Over time there will be multiple "M" platforms and multiple "OS-A" platforms (i.e. there is not just one "OS-A" platform).  Further, there will be updated profiles and platforms every year or two (leaving aside the details).

To start there are two OS-A platforms in the works (with more to be started next year).  The "base/basic" platform (which is expected to be renamed) is intended to provide a broad tent for many types of "rich OS" designs to be able to comply with.  (Although the tension still remains between setting a low bar that standardizes and requires less and setting a higher bar that standardizes and requires more.  No matter what, not everyone will be happy with this or any particular platform.  Which is part of why there will be other platforms as well.)  The "server" platform (also expected to be renamed to avoid improper connotations) will be the first of many more targeted platforms (addressing broad market areas like automotive, HPC, mobile/Android, "server", etc.) that by their nature standardize and require more and set a higher bar.  Some platforms may choose to build on top of another existing platform spec; others may be their own completely independent platform.

For the "basic" platform there should be separate M and S/U platforms (roughly akin to the profile situation).  One can claim compliance and branding with just the "OS-A Basic-SU" platform (the actual name tbd), or with both the "OS-A Basic-SU" and "OS-A Basic-M" platforms.  Tbd whether the latter is solely an "extension or add-on platform" to the former, or is a separate platform that can be used with other "OS-A XXX-SU" platforms as well.  Ditto for other "OS-A XXX-M" platforms that are developed.  And for that matter a more targeted platform may choose to standardize M as well as S and U levels as one platform.

"OS-A SU" platforms are focused on providing OS/User interoperability between hardware and software (whether binary or source interoperability - depending on the particular platform in question).  "OS-A M" platforms are focused on M-level source interoperability for certain components of M-mode software.  An initial "OS-A M" platform would focus on enabling hardware/software source interoperability just for OpenSBI and similar SBI implementations.  Further "OS-A M" platforms will reflect new and growing RISC-V M-level standards in areas like security and focus on enabling a broader range of M-mode hardware/software interoperability (although there will always be platform-specific M-mode software).

In short, as far as the recent discussions about the "OS-A Basic" platform, the "OS-A Basic" platform should really be separated into two pieces.  The "OS-A Basic-SU" platform (until a better and more appropriate name is determined) addresses what a number of people have been desiring and arguing for.  The "OS-A Basic-M" platform is available for people that want to also comply with that.  While others will choose to comply with just the "OS-A Basic-SU" platform.  (Providing, just like the ISA profiles, flexibility for a variety of system implementations.  Which will increase as more platforms are developed.)

Greg


Darius Rad
 

On Wed, Oct 20, 2021 at 09:28:28AM -0700, Greg Favor wrote:

First, for context, just like there are multiple RISC-V ISA profiles, there
will be multiple RISC-V platforms. Taking for example the RVA22 profile,
this is actually three distinct profiles representing M, S, and U
functionality. One can choose to be compliant with one, two, or all three
RVA22 profiles. Similar is true for all the other profiles.
With platforms as the analog to profiles, where is there not a similar
analog below platforms as there are extensions below profiles? For
example, I can easily describe an RV64IMA system, which likely won't be
part of a standard profile, by invoking the standard I, M, and A
extensions. Why can I not do something similar for platforms? I would
like to.

...

For the "basic" platform there should be separate M and S/U platforms
(roughly akin to the profile situation). One can claim compliance and
branding with just the "OS-A Basic-SU" platform (*the actual name tbd*), or
with both the "OS-A Basic-SU" and "OS-A Basic-M" platforms. Tbd whether
the latter is solely an "extension or add-on platform" to the former, or is
a separate platform that can be used with other "OS-A XXX-SU" platforms as
well. Ditto for other "OS-A XXX-M" platforms that are developed. And for
that matter a more targeted platform may choose to standardize M as well as
S and U levels as one platform.

"OS-A SU" platforms are focused on providing OS/User interoperability
between hardware and software (whether binary or source interoperability -
depending on the particular platform in question). "OS-A M" platforms are
focused on M-level source interoperability for certain components of M-mode
software. An initial "OS-A M" platform would focus on enabling
hardware/software source interoperability just for OpenSBI and similar SBI
implementations. Further "OS-A M" platforms will reflect new and growing
RISC-V M-level standards in areas like security and focus on enabling a
broader range of M-mode hardware/software interoperability (although there
will always be platform-specific M-mode software).
What is the motivation for combining S and U mode, as opposed to having
them split? Split seems to make more sense to me, since for example, each
operating system will likely have significant differences at the U level
interface, but could share the same S level interface. The vast majority
of the existing draft OS-A specification deals with S level details anyway,
and what details exist for the U level interface are far from complete.

If we consider the comment above about having an analog to ISA-extensions
for platforms, we could have common sub-platform elements that are shared
for different operating systems (like the ELF, DWARF, and psABI details) as
well as other sub-platform elements that are operating system specific
(e.g., Linux user mode ABI, BSD user mode ABI, etc.).

// darius


Andrew Waterman
 



On Wed, Oct 20, 2021 at 1:41 PM Darius Rad <darius@...> wrote:
On Wed, Oct 20, 2021 at 09:28:28AM -0700, Greg Favor wrote:
>
> First, for context, just like there are multiple RISC-V ISA profiles, there
> will be multiple RISC-V platforms.  Taking for example the RVA22 profile,
> this is actually three distinct profiles representing M, S, and U
> functionality.  One can choose to be compliant with one, two, or all three
> RVA22 profiles.  Similar is true for all the other profiles.
>

With platforms as the analog to profiles, where is there not a similar
analog below platforms as there are extensions below profiles?  For
example, I can easily describe an RV64IMA system, which likely won't be
part of a standard profile, by invoking the standard I, M, and A
extensions.  Why can I not do something similar for platforms?  I would
like to.

> ...
>
> For the "basic" platform there should be separate M and S/U platforms
> (roughly akin to the profile situation).  One can claim compliance and
> branding with just the "OS-A Basic-SU" platform (*the actual name tbd*), or
> with both the "OS-A Basic-SU" and "OS-A Basic-M" platforms.  Tbd whether
> the latter is solely an "extension or add-on platform" to the former, or is
> a separate platform that can be used with other "OS-A XXX-SU" platforms as
> well.  Ditto for other "OS-A XXX-M" platforms that are developed.  And for
> that matter a more targeted platform may choose to standardize M as well as
> S and U levels as one platform.
>
> "OS-A SU" platforms are focused on providing OS/User interoperability
> between hardware and software (whether binary or source interoperability -
> depending on the particular platform in question).  "OS-A M" platforms are
> focused on M-level source interoperability for certain components of M-mode
> software.  An initial "OS-A M" platform would focus on enabling
> hardware/software source interoperability just for OpenSBI and similar SBI
> implementations.  Further "OS-A M" platforms will reflect new and growing
> RISC-V M-level standards in areas like security and focus on enabling a
> broader range of M-mode hardware/software interoperability (although there
> will always be platform-specific M-mode software).
>

What is the motivation for combining S and U mode, as opposed to having
them split?  Split seems to make more sense to me, since for example, each
operating system will likely have significant differences at the U level
interface, but could share the same S level interface.  The vast majority
of the existing draft OS-A specification deals with S level details anyway,
and what details exist for the U level interface are far from complete.

The intent is not to encode the ABI in this profile; rather, it's the interface that OS distributions should target.  Exactly what we name this thing is perhaps debatable.


If we consider the comment above about having an analog to ISA-extensions
for platforms, we could have common sub-platform elements that are shared
for different operating systems (like the ELF, DWARF, and psABI details) as
well as other sub-platform elements that are operating system specific
(e.g., Linux user mode ABI, BSD user mode ABI, etc.).

// darius


Darius Rad
 

On Wed, Oct 20, 2021 at 02:14:38PM -0700, Andrew Waterman wrote:
On Wed, Oct 20, 2021 at 1:41 PM Darius Rad <darius@...> wrote:

On Wed, Oct 20, 2021 at 09:28:28AM -0700, Greg Favor wrote:

First, for context, just like there are multiple RISC-V ISA profiles,
there
will be multiple RISC-V platforms. Taking for example the RVA22 profile,
this is actually three distinct profiles representing M, S, and U
functionality. One can choose to be compliant with one, two, or all
three
RVA22 profiles. Similar is true for all the other profiles.
With platforms as the analog to profiles, where is there not a similar
analog below platforms as there are extensions below profiles? For
example, I can easily describe an RV64IMA system, which likely won't be
part of a standard profile, by invoking the standard I, M, and A
extensions. Why can I not do something similar for platforms? I would
like to.

...

For the "basic" platform there should be separate M and S/U platforms
(roughly akin to the profile situation). One can claim compliance and
branding with just the "OS-A Basic-SU" platform (*the actual name tbd*),
or
with both the "OS-A Basic-SU" and "OS-A Basic-M" platforms. Tbd whether
the latter is solely an "extension or add-on platform" to the former, or
is
a separate platform that can be used with other "OS-A XXX-SU" platforms
as
well. Ditto for other "OS-A XXX-M" platforms that are developed. And
for
that matter a more targeted platform may choose to standardize M as well
as
S and U levels as one platform.

"OS-A SU" platforms are focused on providing OS/User interoperability
between hardware and software (whether binary or source interoperability
-
depending on the particular platform in question). "OS-A M" platforms
are
focused on M-level source interoperability for certain components of
M-mode
software. An initial "OS-A M" platform would focus on enabling
hardware/software source interoperability just for OpenSBI and similar
SBI
implementations. Further "OS-A M" platforms will reflect new and growing
RISC-V M-level standards in areas like security and focus on enabling a
broader range of M-mode hardware/software interoperability (although
there
will always be platform-specific M-mode software).
What is the motivation for combining S and U mode, as opposed to having
them split? Split seems to make more sense to me, since for example, each
operating system will likely have significant differences at the U level
interface, but could share the same S level interface. The vast majority
of the existing draft OS-A specification deals with S level details anyway,
and what details exist for the U level interface are far from complete.
The intent is not to encode the ABI in this profile; rather, it's the
interface that OS distributions should target. Exactly what we name this
thing is perhaps debatable.
Yet there is a section titled "Software and ABIs" in the current
draft, which would suggest otherwise.


If we consider the comment above about having an analog to ISA-extensions
for platforms, we could have common sub-platform elements that are shared
for different operating systems (like the ELF, DWARF, and psABI details) as
well as other sub-platform elements that are operating system specific
(e.g., Linux user mode ABI, BSD user mode ABI, etc.).

// darius