Public review of Supervisor Binary Interface (SBI) Specification


atishp@...
 

I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra


Jonathan Behrens <behrensj@...>
 

If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?

Jonathan


On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra






atishp@...
 

On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:

If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
The description says "Returns 0 if the given SBI extension ID (EID) is
not available, or an extension-specific non-zero value if it is
available"
The specification says it should be non-zero as the value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.

Jonathan

On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:

I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra





Jonathan Behrens <behrensj@...>
 

If that is the intention, the text should be changed to "Returns 0 if the given SBI extension ID (EID) is not available, or an implementation defined non-zero value if it is available". Although, if the extensions aren't defining any meaning to the various possible non-zero values, I personally don't see why we shouldn't change it to "returns one if it is available".

Jonathan


On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra <atishp@...> wrote:
On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:
>
> If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
>

The description says "Returns 0 if the given SBI extension ID (EID) is
not available, or an extension-specific non-zero value if it is
available"
The specification says it should be non-zero as the value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.

> Jonathan
>
> On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
>>
>> I just realized that the below email was not delivered to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment. Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>> -----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public review period for
>> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> SBI specification is considered as frozen now as per the RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>>
>> which was generated from the source available in the following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
>>
>> To respond to the public review, please either reply to this email or
>> send comments to the platform mailing list[1] or add issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform HSC members. Any
>> minor corrections and/or uncontroversial changes will be incorporated
>> into the specification. Any remaining issues or proposed changes will
>> be addressed in the public review summary report. If there are no
>> issues that require incompatible changes to the public review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will evolve over time
>> with new extensions as long as they are backward compatible. Any such
>> proposals for new extensions can be included in the future releases
>> after proper discussions in the platform working group meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
>> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>


Andrew Waterman
 



On Wed, Jan 12, 2022 at 12:50 PM Jonathan Behrens <behrensj@...> wrote:
If that is the intention, the text should be changed to "Returns 0 if the given SBI extension ID (EID) is not available, or an implementation defined non-zero value if it is available". Although, if the extensions aren't defining any meaning to the various possible non-zero values, I personally don't see why we shouldn't change it to "returns one if it is available".

I think allowing implementation-defined nonzero rather than requiring it be 1 is OK, but I agree with your proposed wording change.


Jonathan

On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra <atishp@...> wrote:
On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:
>
> If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
>

The description says "Returns 0 if the given SBI extension ID (EID) is
not available, or an extension-specific non-zero value if it is
available"
The specification says it should be non-zero as the value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.

> Jonathan
>
> On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
>>
>> I just realized that the below email was not delivered to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment. Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>> -----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public review period for
>> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> SBI specification is considered as frozen now as per the RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>>
>> which was generated from the source available in the following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
>>
>> To respond to the public review, please either reply to this email or
>> send comments to the platform mailing list[1] or add issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform HSC members. Any
>> minor corrections and/or uncontroversial changes will be incorporated
>> into the specification. Any remaining issues or proposed changes will
>> be addressed in the public review summary report. If there are no
>> issues that require incompatible changes to the public review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will evolve over time
>> with new extensions as long as they are backward compatible. Any such
>> proposals for new extensions can be included in the future releases
>> after proper discussions in the platform working group meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
>> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>


Andrew Waterman
 

Hi Atish,

I've got some minor feedback from the Architecture Review committee:

We think that only the RV64 SBI should be ratified at this time.  The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.

It would be helpful to add some non-normative text about what the SBI assumes about discovery.  For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.

Thanks,
Andrew

On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra






Anup Patel
 

HI Andrew,

On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:

Hi Atish,

I've got some minor feedback from the Architecture Review committee:

We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
The RV32 physical address space limitation only impacts SBI RFENCE
calls and SBI HSM calls. A RV32 system can still use these calls as
long as their physical address space is within 4GB.

I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
chapters for SBI v1.0 and plan to address this in SBI v2.0.


It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
I agree with this suggestion. We got this question multiple times in
the past as well.

Regards,
Anup


Thanks,
Andrew

On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:

I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra





Andrew Waterman
 



On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:
HI Andrew,

On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
>
> Hi Atish,
>
> I've got some minor feedback from the Architecture Review committee:
>
> We think that only the RV64 SBI should be ratified at this time.  The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.

The RV32 physical address space limitation only impacts SBI RFENCE
calls and SBI HSM calls. A RV32 system can still use these calls as
long as their physical address space is within 4GB.

I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
chapters for SBI v1.0 and plan to address this in SBI v2.0.

It's true that specific example is limited to those calls, but I'll re-emphase the "e.g."  The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them.  So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.


>
> It would be helpful to add some non-normative text about what the SBI assumes about discovery.  For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.

I agree with this suggestion. We got this question multiple times in
the past as well.

Cool, thanks!
 

Regards,
Anup

>
> Thanks,
> Andrew
>
> On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
>>
>> I just realized that the below email was not delivered to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment. Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>> -----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public review period for
>> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> SBI specification is considered as frozen now as per the RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>>
>> which was generated from the source available in the following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
>>
>> To respond to the public review, please either reply to this email or
>> send comments to the platform mailing list[1] or add issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform HSC members. Any
>> minor corrections and/or uncontroversial changes will be incorporated
>> into the specification. Any remaining issues or proposed changes will
>> be addressed in the public review summary report. If there are no
>> issues that require incompatible changes to the public review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will evolve over time
>> with new extensions as long as they are backward compatible. Any such
>> proposals for new extensions can be included in the future releases
>> after proper discussions in the platform working group meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
>> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>


atishp@...
 

On Tue, Jan 18, 2022 at 10:08 PM Andrew Waterman <andrew@...> wrote:



On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:

HI Andrew,

On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:

Hi Atish,

I've got some minor feedback from the Architecture Review committee:

We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
The RV32 physical address space limitation only impacts SBI RFENCE
calls and SBI HSM calls. A RV32 system can still use these calls as
long as their physical address space is within 4GB.

I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
chapters for SBI v1.0 and plan to address this in SBI v2.0.

It's true that specific example is limited to those calls, but I'll re-emphase the "e.g." The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them. So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.
Sure. Here is the proposed diff that removed all the references to
RV32 in the specification.
Is it a common practice to explicitly specify in the specification
that only the RV64 version is ratified ?
We can add it to the release notes. Please let me know if there are
any other places it should be specified.
-------------------------------------------------------------------------------------------------------------
diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc
index be753a596837..09061e5e4b3b 100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -90,7 +90,7 @@ function calls except that:

* An `ECALL` is used as the control transfer instruction instead of a `CALL`
instruction.
-* `a7` (or `t0` on RV32E-based systems) encodes the SBI extension ID (*EID*),
+* `a7` encodes the SBI extension ID (*EID*),
which matches how the system call ID is encoded in Linux system call ABI.

Many SBI extensions also chose to encode an additional SBI function ID (*FID*)
@@ -136,9 +136,9 @@ An `ECALL` with an unsupported SBI extension ID
(*EID*) or an unsupported SBI
function ID (*FID*) must return the error code `SBI_ERR_NOT_SUPPORTED`.

Every SBI function should prefer `unsigned long` as the data type. It keeps
-the specification simple and easily adaptable for all RISC-V ISA types (i.e.
-RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher
-privilege software must ensure that it only uses 32 bit data only.
+the specification simple and easily adaptable for all RISC-V ISA types.
+In case the data is defined as 32bit wide, higher privilege software must
+ensure that it only uses 32 bit data only.

If an SBI function needs to pass a list of harts to the higher privilege mode,
it must use a hart mask as defined below. This is applicable to any extensions
@@ -977,7 +977,7 @@ shown in <<table_hsm_hart_suspend_types>> below.
| 0x80000000 | Default non-retentive suspend
| 0x80000001 - 0x8FFFFFFF | Reserved for future use
| 0x90000000 - 0xFFFFFFFF | Platform specific non-retentive suspend
-| > 0xFFFFFFFF | Reserved (and non-existent on RV32)
+| > 0xFFFFFFFF | Reserved
|===

The `resume_addr` parameter points to a runtime-specified physical address,
@@ -1051,7 +1051,7 @@ in the <<table_srst_system_reset_types>> below.
| 0x00000002 | Warm reboot
| 0x00000003 - 0xEFFFFFFF | Reserved for future use
| 0xF0000000 - 0xFFFFFFFF | Vendor or platform specific reset type
-| > 0xFFFFFFFF | Reserved (and non-existent on RV32)
+| > 0xFFFFFFFF | Reserved
|===

The `reset_reason` is an optional parameter representing the reason for
@@ -1068,7 +1068,7 @@ in the <<table_srst_system_reset_reasons>> below
| 0x00000002 - 0xDFFFFFFF | Reserved for future use
| 0xE0000000 - 0xEFFFFFFF | SBI implementation specific reset reason
| 0xF0000000 - 0xFFFFFFFF | Vendor or platform specific reset reason
-| > 0xFFFFFFFF | Reserved (and non-existent on RV32)
+| > 0xFFFFFFFF | Reserved
|===

-------------------------------------------------------------------------------------------------------------


It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
I agree with this suggestion. We got this question multiple times in
the past as well.
I will send a separate patch for this.


Cool, thanks!



Regards,
Anup


Thanks,
Andrew

On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:

I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra





Anup Patel
 

Hi Andrew,

On Wed, Jan 19, 2022 at 11:38 AM Andrew Waterman <andrew@...> wrote:



On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:

HI Andrew,

On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:

Hi Atish,

I've got some minor feedback from the Architecture Review committee:

We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
The RV32 physical address space limitation only impacts SBI RFENCE
calls and SBI HSM calls. A RV32 system can still use these calls as
long as their physical address space is within 4GB.

I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
chapters for SBI v1.0 and plan to address this in SBI v2.0.

It's true that specific example is limited to those calls, but I'll re-emphase the "e.g." The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them. So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.
I mostly agree with your suggestion considering the fact that we have
very few (or none) RV32 Linux (or RichOS) capable systems.

I would also like to correct my previous comment about the RV32
limitation. The RV32 limitation only affects SBI HSM and does not
affect any other SBI extension (including SBI RFENCE) because SBI
RFENCE calls take virtual address as "unsigned long" parameter. In
other words, on a RV32 system the SBI HSM start and suspend calls will
need a physical address within the 4GB address range.

Regards,
Anup




It would be helpful to add some non-normative text about what the SBI assumes about discovery. For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
I agree with this suggestion. We got this question multiple times in
the past as well.

Cool, thanks!



Regards,
Anup


Thanks,
Andrew

On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:

I just realized that the below email was not delivered to unix
platform mailing list and
linux-riscv mailing list because of the attachment. Reseeding it again
without the
attachment. Apologies for the noise.

-----------------------------------------------------------------------------------------------
We are delighted to announce the start of the public review period for
the Non-ISA Supervisor Binary Interface (SBI) specification. The
SBI specification is considered as frozen now as per the RISC-V International
policies.

The review period begins today, Monday Jan 10, and ends on Monday
Jan 24 (inclusive).

The specification can be found here
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf

which was generated from the source available in the following GitHub
repository:
https://github.com/riscv-non-isa/riscv-sbi-doc

To respond to the public review, please either reply to this email or
send comments to the platform mailing list[1] or add issues to the
SBI GitHub repo[2]. We welcome all input and appreciate your time and
effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Platform HSC members. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the platform HSC will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.

SBI specification is non-ISA specifications and will evolve over time
with new extensions as long as they are backward compatible. Any such
proposals for new extensions can be included in the future releases
after proper discussions in the platform working group meetings.

Thanks to all the contributors for all their hard work.

[1] tech-unixplatformspec@...
[2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues

Regards,
Atish Patra





Andrew Waterman
 



On Wed, Jan 19, 2022 at 3:10 AM Anup Patel <apatel@...> wrote:
Hi Andrew,

On Wed, Jan 19, 2022 at 11:38 AM Andrew Waterman <andrew@...> wrote:
>
>
>
> On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:
>>
>> HI Andrew,
>>
>> On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
>> >
>> > Hi Atish,
>> >
>> > I've got some minor feedback from the Architecture Review committee:
>> >
>> > We think that only the RV64 SBI should be ratified at this time.  The RV32 variants are likely to need some reworking (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
>>
>> The RV32 physical address space limitation only impacts SBI RFENCE
>> calls and SBI HSM calls. A RV32 system can still use these calls as
>> long as their physical address space is within 4GB.
>>
>> I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
>> chapters for SBI v1.0 and plan to address this in SBI v2.0.
>
>
> It's true that specific example is limited to those calls, but I'll re-emphase the "e.g."  The RV32 variants have not gotten much road testing because there isn't much demand for them--which again calls into question why we are rushing to ratify them.  So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.

I mostly agree with your suggestion considering the fact that we have
very few (or none) RV32 Linux (or RichOS) capable systems.

Indeed.  I'm sure we'll cross that bridge eventually (at which point ratification should be very smooth).
 

I would also like to correct my previous comment about the RV32
limitation. The RV32 limitation only affects SBI HSM and does not
affect any other SBI extension (including SBI RFENCE) because SBI
RFENCE calls take virtual address as "unsigned long" parameter. In
other words, on a RV32 system the SBI HSM start and suspend calls will
need a physical address within the 4GB address range.

Regards,
Anup

>
>>
>> >
>> > It would be helpful to add some non-normative text about what the SBI assumes about discovery.  For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
>>
>> I agree with this suggestion. We got this question multiple times in
>> the past as well.
>
>
> Cool, thanks!
>
>>
>>
>> Regards,
>> Anup
>>
>> >
>> > Thanks,
>> > Andrew
>> >
>> > On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
>> >>
>> >> I just realized that the below email was not delivered to unix
>> >> platform mailing list and
>> >> linux-riscv mailing list because of the attachment. Reseeding it again
>> >> without the
>> >> attachment. Apologies for the noise.
>> >>
>> >> -----------------------------------------------------------------------------------------------
>> >> We are delighted to announce the start of the public review period for
>> >> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> >> SBI specification is considered as frozen now as per the RISC-V International
>> >> policies.
>> >>
>> >> The review period begins today, Monday Jan 10, and ends on Monday
>> >> Jan 24 (inclusive).
>> >>
>> >> The specification can be found here
>> >> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>> >>
>> >> which was generated from the source available in the following GitHub
>> >> repository:
>> >> https://github.com/riscv-non-isa/riscv-sbi-doc
>> >>
>> >> To respond to the public review, please either reply to this email or
>> >> send comments to the platform mailing list[1] or add issues to the
>> >> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> >> effort in helping us by reviewing the specification.
>> >>
>> >> During the public review period, corrections, comments, and
>> >> suggestions, will be gathered for review by the Platform HSC members. Any
>> >> minor corrections and/or uncontroversial changes will be incorporated
>> >> into the specification. Any remaining issues or proposed changes will
>> >> be addressed in the public review summary report. If there are no
>> >> issues that require incompatible changes to the public review
>> >> specification, the platform HSC will recommend the updated
>> >> specifications be approved and ratified by the RISC-V Technical
>> >> Steering Committee and the RISC-V Board of Directors.
>> >>
>> >> SBI specification is non-ISA specifications and will evolve over time
>> >> with new extensions as long as they are backward compatible. Any such
>> >> proposals for new extensions can be included in the future releases
>> >> after proper discussions in the platform working group meetings.
>> >>
>> >> Thanks to all the contributors for all their hard work.
>> >>
>> >> [1] tech-unixplatformspec@...
>> >> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>> >>
>> >> Regards,
>> >> Atish Patra
>> >>
>> >>
>> >>
>> >>
>> >>


merle w
 

3.4. Function: Probe SBI extension (FID #3)
struct sbiret sbi_probe_extension(long extension_id);
Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero
value if it is available.

Do we need to add more fine-grained detection to check if a certain funcid is available


atishp@...
 

On Thu, Jan 20, 2022 at 6:23 PM <merlew4n6@...> wrote:

3.4. Function: Probe SBI extension (FID #3)
struct sbiret sbi_probe_extension(long extension_id);
Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero
value if it is available.

Do we need to add more fine-grained detection to check if a certain funcid is available
That won't be required as the specification clearly states that

"SBI extensions as whole are optional but they shall not be partially
implemented. If sbi_probe_extension() signals that an extension is
available, all functions present in the SBI version reported by
sbi_get_spec_version() must conform to that version of the SBI
specification."


merle w
 

Thank you for your reply


atishp@...
 



On Tue, Jan 18, 2022 at 2:46 PM Andrew Waterman <andrew@...> wrote:


On Wed, Jan 12, 2022 at 12:50 PM Jonathan Behrens <behrensj@...> wrote:
If that is the intention, the text should be changed to "Returns 0 if the given SBI extension ID (EID) is not available, or an implementation defined non-zero value if it is available". Although, if the extensions aren't defining any meaning to the various possible non-zero values, I personally don't see why we shouldn't change it to "returns one if it is available".

I think allowing implementation-defined nonzero rather than requiring it be 1 is OK, but I agree with your proposed wording change.


Sounds good to me as well. I will make the change.
 

Jonathan

On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra <atishp@...> wrote:
On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens <behrensj@...> wrote:
>
> If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However, right now I don't think any of them do. Is this something that should be fixed?
>

The description says "Returns 0 if the given SBI extension ID (EID) is
not available, or an extension-specific non-zero value if it is
available"
The specification says it should be non-zero as the value "0"
indicates non-availability of the extension. The exact return value
should be an implementation detail.

> Jonathan
>
> On Wed, Jan 12, 2022 at 1:44 PM atishp via lists.riscv.org <atishp=rivosinc.com@...> wrote:
>>
>> I just realized that the below email was not delivered to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment. Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>> -----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public review period for
>> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> SBI specification is considered as frozen now as per the RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>>
>> which was generated from the source available in the following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
>>
>> To respond to the public review, please either reply to this email or
>> send comments to the platform mailing list[1] or add issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform HSC members. Any
>> minor corrections and/or uncontroversial changes will be incorporated
>> into the specification. Any remaining issues or proposed changes will
>> be addressed in the public review summary report. If there are no
>> issues that require incompatible changes to the public review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will evolve over time
>> with new extensions as long as they are backward compatible. Any such
>> proposals for new extensions can be included in the future releases
>> after proper discussions in the platform working group meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
>> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>


Heinrich Schuchardt
 

On 1/27/22 09:33, atishp@... wrote:
On Tue, Jan 18, 2022 at 2:46 PM Andrew Waterman <andrew@... <mailto:andrew@...>> wrote:
On Wed, Jan 12, 2022 at 12:50 PM Jonathan Behrens <behrensj@...
<mailto:behrensj@...>> wrote:
If that is the intention, the text should be changed to "Returns
0 if the given SBI extension ID (EID) is not available, or an
*implementation defined* non-zero value if it is available".
Although, if the extensions aren't defining any meaning to the
various possible non-zero values, I personally don't see why we
shouldn't change it to "returns one if it is available".
I think allowing implementation-defined nonzero rather than
requiring it be 1 is OK, but I agree with your proposed wording change.
Sounds good to me as well. I will make the change.
Why should the value be implementation specific and not extension specific?

I would prefer if the specification would provide extension specific unique return values instead of introducing ambiguity about possible return values.

This also allows us to define further return values per extension if needed in future. But currently all of these values can be defined as 1.

We just have to add this value 1 to each extension description.

Best regards

Heinrich

Jonathan
On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra
<atishp@... <mailto:atishp@...>> wrote:
On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens
<behrensj@... <mailto:behrensj@...>> wrote:
>
> If I understand correctly, per the description of
`sbi_probe_extension`, each of the extensions are supposed
to specify an "extension-specific non-zero value" to return
if they are available. However, right now I don't think any
of them do. Is this something that should be fixed?
>
The description says "Returns 0 if the given SBI extension
ID (EID) is
not available, or an extension-specific non-zero value if it is
available"
The specification says it should be non-zero as the value "0"
indicates non-availability of the extension. The exact
return value
should be an implementation detail.

> Jonathan
>
> On Wed, Jan 12, 2022 at 1:44 PM atishp via
lists.riscv.org <http://lists.riscv.org>
<atishp=rivosinc.com@...
<mailto:rivosinc.com@...>> wrote:
>>
>> I just realized that the below email was not delivered
to unix
>> platform mailing list and
>> linux-riscv mailing list because of the attachment.
Reseeding it again
>> without the
>> attachment. Apologies for the noise.
>>
>>
-----------------------------------------------------------------------------------------------
>> We are delighted to announce the start of the public
review period for
>> the Non-ISA Supervisor Binary Interface (SBI)
specification. The
>> SBI specification is considered as frozen now as per the
RISC-V International
>> policies.
>>
>> The review period begins today, Monday Jan 10, and ends
on Monday
>> Jan 24 (inclusive).
>>
>> The specification can be found here
>>
https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
<https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf>
>>
>> which was generated from the source available in the
following GitHub
>> repository:
>> https://github.com/riscv-non-isa/riscv-sbi-doc
<https://github.com/riscv-non-isa/riscv-sbi-doc>
>>
>> To respond to the public review, please either reply to
this email or
>> send comments to the platform mailing list[1] or add
issues to the
>> SBI GitHub repo[2]. We welcome all input and appreciate
your time and
>> effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and
>> suggestions, will be gathered for review by the Platform
HSC members. Any
>> minor corrections and/or uncontroversial changes will be
incorporated
>> into the specification. Any remaining issues or proposed
changes will
>> be addressed in the public review summary report. If
there are no
>> issues that require incompatible changes to the public
review
>> specification, the platform HSC will recommend the updated
>> specifications be approved and ratified by the RISC-V
Technical
>> Steering Committee and the RISC-V Board of Directors.
>>
>> SBI specification is non-ISA specifications and will
evolve over time
>> with new extensions as long as they are backward
compatible. Any such
>> proposals for new extensions can be included in the
future releases
>> after proper discussions in the platform working group
meetings.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> [1] tech-unixplatformspec@...
<mailto:tech-unixplatformspec@...>
>> [2]
https://github.com/riscv-non-isa/riscv-sbi-doc/issues
<https://github.com/riscv-non-isa/riscv-sbi-doc/issues>
>>
>> Regards,
>> Atish Patra
>>
>>
>>
>>
>>


atishp@...
 



On Thu, Jan 27, 2022 at 12:57 AM Heinrich Schuchardt <heinrich.schuchardt@...> wrote:
On 1/27/22 09:33, atishp@... wrote:
>
>
> On Tue, Jan 18, 2022 at 2:46 PM Andrew Waterman <andrew@...
> <mailto:andrew@...>> wrote:
>
>
>
>     On Wed, Jan 12, 2022 at 12:50 PM Jonathan Behrens <behrensj@...
>     <mailto:behrensj@...>> wrote:
>
>         If that is the intention, the text should be changed to "Returns
>         0 if the given SBI extension ID (EID) is not available, or an
>         *implementation defined* non-zero value if it is available".
>         Although, if the extensions aren't defining any meaning to the
>         various possible non-zero values, I personally don't see why we
>         shouldn't change it to "returns one if it is available".
>
>
>     I think allowing implementation-defined nonzero rather than
>     requiring it be 1 is OK, but I agree with your proposed wording change.
>
>
> Sounds good to me as well. I will make the change.

Why should the value be implementation specific and not extension specific?


There was no need for any extension specific return value yet. I doubt if we will need one
in the future.
 
To reduce ambiguity, how about this change:

"Returns 0 if the given SBI extension ID (EID) is not available, or 1 if it is available unless 
defined as any other non-zero value by the implementation."

This aligns with what Andrew suggested and is compatible with all the existing implementations.

I would prefer if the specification would provide extension specific
unique return values instead of introducing ambiguity about possible
return values.

This also allows us to define further return values per extension if
needed in future. But currently all of these values can be defined as 1.

We just have to add this value 1 to each extension description.

Best regards

Heinrich

>
>
>         Jonathan
>
>         On Wed, Jan 12, 2022 at 3:32 PM Atish Kumar Patra
>         <atishp@... <mailto:atishp@...>> wrote:
>
>             On Wed, Jan 12, 2022 at 10:59 AM Jonathan Behrens
>             <behrensj@... <mailto:behrensj@...>> wrote:
>              >
>              > If I understand correctly, per the description of
>             `sbi_probe_extension`, each of the extensions are supposed
>             to specify an "extension-specific non-zero value" to return
>             if they are available. However, right now I don't think any
>             of them do. Is this something that should be fixed?
>              >
>
>             The description says "Returns 0 if the given SBI extension
>             ID (EID) is
>             not available, or an extension-specific non-zero value if it is
>             available"
>             The specification says it should be non-zero as the value "0"
>             indicates non-availability of the extension. The exact
>             return value
>             should be an implementation detail.
>
>              > Jonathan
>              >
>              > On Wed, Jan 12, 2022 at 1:44 PM atishp via
>             lists.riscv.org <http://lists.riscv.org>
>             <atishp=rivosinc.com@...
>             <mailto:rivosinc.com@...>> wrote:
>              >>
>              >> I just realized that the below email was not delivered
>             to unix
>              >> platform mailing list and
>              >> linux-riscv mailing list because of the attachment.
>             Reseeding it again
>              >> without the
>              >> attachment. Apologies for the noise.
>              >>
>              >>
>             -----------------------------------------------------------------------------------------------
>              >> We are delighted to announce the start of the public
>             review period for
>              >> the Non-ISA Supervisor Binary Interface (SBI)
>             specification. The
>              >> SBI specification is considered as frozen now as per the
>             RISC-V International
>              >> policies.
>              >>
>              >> The review period begins today, Monday Jan 10, and ends
>             on Monday
>              >> Jan 24 (inclusive).
>              >>
>              >> The specification can be found here
>              >>
>             https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>             <https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf>
>              >>
>              >> which was generated from the source available in the
>             following GitHub
>              >> repository:
>              >> https://github.com/riscv-non-isa/riscv-sbi-doc
>             <https://github.com/riscv-non-isa/riscv-sbi-doc>
>              >>
>              >> To respond to the public review, please either reply to
>             this email or
>              >> send comments to the platform mailing list[1] or add
>             issues to the
>              >> SBI GitHub repo[2]. We welcome all input and appreciate
>             your time and
>              >> effort in helping us by reviewing the specification.
>              >>
>              >> During the public review period, corrections, comments, and
>              >> suggestions, will be gathered for review by the Platform
>             HSC members. Any
>              >> minor corrections and/or uncontroversial changes will be
>             incorporated
>              >> into the specification. Any remaining issues or proposed
>             changes will
>              >> be addressed in the public review summary report. If
>             there are no
>              >> issues that require incompatible changes to the public
>             review
>              >> specification, the platform HSC will recommend the updated
>              >> specifications be approved and ratified by the RISC-V
>             Technical
>              >> Steering Committee and the RISC-V Board of Directors.
>              >>
>              >> SBI specification is non-ISA specifications and will
>             evolve over time
>              >> with new extensions as long as they are backward
>             compatible. Any such
>              >> proposals for new extensions can be included in the
>             future releases
>              >> after proper discussions in the platform working group
>             meetings.
>              >>
>              >> Thanks to all the contributors for all their hard work.
>              >>
>              >> [1] tech-unixplatformspec@...
>             <mailto:tech-unixplatformspec@...>
>              >> [2]
>             https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>             <https://github.com/riscv-non-isa/riscv-sbi-doc/issues>
>              >>
>              >> Regards,
>              >> Atish Patra
>              >>
>              >>
>              >>
>              >>
>              >>
>