Date   

Re: Watchdog timer per hart?

Kumar Sankaran
 

From a platform standpoint, the intent was to have a single platform
level watchdog that is shared across the entire platform. This
platform watchdog could be the 2-level watchdog as described below by
Greg. Whether S-mode software or M-mode software would handle the
tickling of this watchdog and handle timeouts is a subject for further
discussion.

On Wed, Mar 2, 2022 at 12:34 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 2, 2022 at 12:23 PM Aaron Durbin <adurbin@...> wrote:

Yes. Greg articulated what I was getting at better than I did. I apologize for muddying the waters. From a platform standpoint one system-level watchdog should suffice as it's typically the last resort of restarting a system prior to sending a tech out.

One comment - for when any concrete discussion about having a system-level watchdog occurs:

One can have a one-stage or a two-stage watchdog. The former yanks the emergency cord on the system upon timeout.

The latter (which is what ARM defined in SBSA and the subsequent SBA) interrupts the OS on the first timeout and gives it a chance to take remedial actions (and refresh the watchdog). Then, if a second timeout occurs (without a refresh after the first timeout), the emergency cord is yanked.

ARM also defined separate Secure and Non-Secure watchdogs (akin to what one might call S-mode and M-mode watchdogs). The OS has its own watchdog to tickle and an emergency situation results in reboot of the OS (for example). And the Secure Monitor has its own watchdog and an emergency situation results in reboot of the system (for example).

Greg

--
Regards
Kumar


Re: Watchdog timer per hart?

Greg Favor
 

On Wed, Mar 2, 2022 at 12:23 PM Aaron Durbin <adurbin@...> wrote:
Yes. Greg articulated what I was getting at better than I did. I apologize for muddying the waters. From a platform standpoint one system-level watchdog should suffice as it's typically the last resort of restarting a system prior to sending a tech out. 

One comment - for when any concrete discussion about having a system-level watchdog occurs:

One can have a one-stage or a two-stage watchdog.  The former yanks the emergency cord on the system upon timeout.  

The latter (which is what ARM defined in SBSA and the subsequent SBA) interrupts the OS on the first timeout and gives it a chance to take remedial actions (and refresh the watchdog).  Then, if a second timeout occurs (without a refresh after the first timeout), the emergency cord is yanked.

ARM also defined separate Secure and Non-Secure watchdogs (akin to what one might call S-mode and M-mode watchdogs).  The OS has its own watchdog to tickle and an emergency situation results in reboot of the OS (for example).  And the Secure Monitor has its own watchdog and an emergency situation results in reboot of the system (for example).

Greg


Re: Watchdog timer per hart?

Aaron Durbin
 

On Wed, Mar 2, 2022 at 1:19 PM Greg Favor <gfavor@...> wrote:
A core-level watchdog can mean quite different things to different people and their core designs.  In some cases this "watchdog" would be a micro-architectural thing that, for example, recognizes that the core is not making forward progress and would temporarily invoke some low-performance uarch mechanism that guarantees forward progress (out of the circumstances currently causing livelock).  Although the details of that very much depend on what types of livelock causes one is concerned about.  In other cases this "watchdog" might generate a local interrupt to take the core into a "lack of forward progress" software handler; or a global interrupt to inform someone else that this core is livelocked.

In general, there's an enormous range of possibilities as to what a core-level watchdog means.  And an enormous range as to what one is trying to accomplish or defend against.

Yes. Greg articulated what I was getting at better than I did. I apologize for muddying the waters. From a platform standpoint one system-level watchdog should suffice as it's typically the last resort of restarting a system prior to sending a tech out. 
 

Greg


On Wed, Mar 2, 2022 at 12:09 PM James Robinson <jrobinson@...> wrote:
Hi Aaron,

Thanks for the response. Would you be able to give any more details on how a core level watchdog would differ from a platform level one?

James


Re: Watchdog timer per hart?

Greg Favor
 

A core-level watchdog can mean quite different things to different people and their core designs.  In some cases this "watchdog" would be a micro-architectural thing that, for example, recognizes that the core is not making forward progress and would temporarily invoke some low-performance uarch mechanism that guarantees forward progress (out of the circumstances currently causing livelock).  Although the details of that very much depend on what types of livelock causes one is concerned about.  In other cases this "watchdog" might generate a local interrupt to take the core into a "lack of forward progress" software handler; or a global interrupt to inform someone else that this core is livelocked.

In general, there's an enormous range of possibilities as to what a core-level watchdog means.  And an enormous range as to what one is trying to accomplish or defend against.

Greg


On Wed, Mar 2, 2022 at 12:09 PM James Robinson <jrobinson@...> wrote:
Hi Aaron,

Thanks for the response. Would you be able to give any more details on how a core level watchdog would differ from a platform level one?

James


Re: Watchdog timer per hart?

James Robinson
 

Hi Aaron,

Thanks for the response. Would you be able to give any more details on how a core level watchdog would differ from a platform level one?

James


Re: Watchdog timer per hart?

Aaron Durbin
 



On Wed, Mar 2, 2022 at 12:35 AM James Robinson <jrobinson@...> wrote:
Hi Greg,

Thanks for your response. I'm not sure if I'm missing something about there being a connection between having a supervisor level watchdog timer and having a timer per hart, but I wasn't particularly imagining a distinction between machine and supervisor mode watch dog timers. I'll repose the question I was thinking about:

Suppose I have a system containing 16 harts. Should I have a separate WDCSR memory mapped register and associated counter for each of the 16 harts, with each counter directing an interrupt to its associated hart if it is not reset before the timeout expires? Or should I have one WDCSR memory mapped register and associated counter for the whole system, with the interrupt directed to one specific hart, and that hart being responsible for responding to a lack of timer update?

If one is operating the machine with 16 harts without any sharding or partitioning, I don't see why one would need a watchdog per hart. System watchdogs, or TCO timers from other architecture's parlance, are for system use. Now a core would normally have it's own watchdog for instruction retirement forward progress purposes, but that's a completely different use-case than the intention of a system level watchdog.

As for Greg's question about putting that in OS-A SEE or a Platform itself, I'm open to suggestions. However, my initial thinking is that it would be deferred to a Platform. The thinking is that OS-A SEE is about targeting SW expectations for the kernel. Kernels are really good about runtime binding of drivers based on the presence of hardware so I'm not overly inclined to mandate such things. That said, I'd be open to hear other opinions.


Thanks,
James


Re: Watchdog timer per hart?

James Robinson
 

Hi Greg,

Thanks for your response. I'm not sure if I'm missing something about there being a connection between having a supervisor level watchdog timer and having a timer per hart, but I wasn't particularly imagining a distinction between machine and supervisor mode watch dog timers. I'll repose the question I was thinking about:

Suppose I have a system containing 16 harts. Should I have a separate WDCSR memory mapped register and associated counter for each of the 16 harts, with each counter directing an interrupt to its associated hart if it is not reset before the timeout expires? Or should I have one WDCSR memory mapped register and associated counter for the whole system, with the interrupt directed to one specific hart, and that hart being responsible for responding to a lack of timer update?

Thanks,
James


Re: Watchdog timer per hart?

Greg Favor
 

On Mon, Feb 28, 2022 at 6:18 PM James Robinson <jrobinson@...> wrote:

Is it expected that there should be a watchdog timer and timeout signal per hart in the system, or is okay for there to be one timer in the system and for the timeout signal to be delivered to a specific hart?

For now (this year) RVI is focusing on standardizing an initial OS-A SEE (Supervisor Execution Environment) and an OS-A Platform standardizing Supervisor and User level functionality, i.e. not Machine-level functionality.  While that doesn't rule out incorporating some form of Supervisor-level watchdog standardization into these specs, I think (?) the current thoughts are not focused on doing so.

FYI - Last year there was an initial proposal for standard hardware watchdog functionality, and then later a proposal instead for an SBI API (e.g. a call to tickle the supervisor watchdog, and a callback on a first-stage timeout).

But certainly speak up with your own arguments or justifications for having and standardizing supervisor watchdog functionality.  (Note: ARM SBSA - for server and high-end embedded class systems - defined and required the equivalent of S-mode (aka Non-Secure) and M-mode (aka Secure) two-stage watchdog functionality.)

Aaron (acting chair of the OS-A SEE TG) and others in the OS-A SEE group, what do you think?  Should some form of support for Supervisor software tickling a watchdog through some form of standardized hardware (e.g. memory-mapped registers) or software (e.g. SBI) interface be included in the OS-A SEE spec?

Greg



Watchdog timer per hart?

James Robinson
 

Is it expected that there should be a watchdog timer and timeout signal per hart in the system, or is okay for there to be one timer in the system and for the timeout signal to be delivered to a specific hart?

Thanks,
James


Next Platform HSC Meeting on Wed Feb 23rd 2022 9AM PST

Kumar Sankaran
 

Hi All,
The next platform HSC meeting is scheduled on Wed Feb 23rd 2022 at 9AM PST.
This meeting is moved to Wed as Monday Feb 21st is a holiday for President's
Day in the US.

Here are the details:

Agenda and minutes kept on the github wiki:
https://github.com/riscv/riscv-platform-specs/wiki

Meeting info
Zoom meeting: https://zoom.us/j/2786028446
Passcode: 901897

Or iPhone one-tap :
US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 278 602 8446
International numbers available:
https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_

Regards
Kumar


Re: Possible progress on M Platform?

Philipp Tomsich <philipp.tomsich@...>
 

Chris,

The Platforms effort is being reorganized and we'll spin up a task group for RVM-CSI (a source-level abstraction framework) up in the near future.
RVM-CSI is very much in focus (for the Software HC's ecosystem efforts), and the goal is to sprint towards a first draft late in the year.
The discussions have been going on for a while and led to Alibaba donating their documentation and sources.

The plan is to draw inspiration from Alibaba's donated abstraction layer (just as well as what our other members bring to the table), from what exists in competing ecosystems, and from the abstractions standardized in C17 a.k.a. ISO/IEC 9899:2018 (e.g., atomics, mutexes, conditions, threads, memory management) to specify a thin (as in "flexible" and "unintrusive"), best-in-class abstraction with C-language bindings for a self-contained small subset (enough to bring up a platform and handle interrupts) of the platform as phase 1.

Follow-on efforts will then add abstractions for additional features of common platforms (e.g. common peripherals, networking, data processing, AI/ML, …) and standardize language bindings for C++ and Rust.

Philipp.





On Mon, 7 Feb 2022 at 21:38, Greg Favor <gfavor@...> wrote:
Chris,

I'm cc'ing the chairs of the Software HC and the Platforms HSC.  All platform efforts are being re-organized a bit as we speak (compared to thus far one group was trying to address a number of needs at both HSC and TG levels but, not surprisingly, only able to focus on one TG effort).  There will be a separate TG created to focus on the "M" platform (under a new name).  Philipp and Kumar will be driving setting that up and will be interested to talk with you.

Greg

P.S. This email list also needs to be replaced by a set of lists (for the HSC and for each new SIG/TG), with appropriate new naming of each list.

On Mon, Feb 7, 2022 at 10:26 AM Chris Owen <Chris.Owen@...> wrote:
Hi all,

I lead the CPU software / SDK team at Imagination Technologies, we are entering the RISC-V space but I'm still quite new around here.

At present we are most interested in embedded applications and I am particularly interested in standardising platform aspects in this area.  For example, a Hardware Adaption Layer for bare-metal apps.  I realise, though, that the M platform is rather on hold and all the focus is on OS-A.

Is this the only mailing list for the Platforms HSC?  Or is there another one which could be used for discussions around the M platform?  I realise the title for this list says its for unix-class, but I didn't see any other...

I was just wondering if we could start progressing M platform in parallel with OS-A.  My team and I are ready and willing to engage in this area.  I believe people like SiFive and AliBaba have done lots of work in this area and it would be great to bring them together and standardise rather than allowing things to fragment further.

Thanks for any help and advice,
Chris Owen


Re: Possible progress on M Platform?

Greg Favor
 

Chris,

I'm cc'ing the chairs of the Software HC and the Platforms HSC.  All platform efforts are being re-organized a bit as we speak (compared to thus far one group was trying to address a number of needs at both HSC and TG levels but, not surprisingly, only able to focus on one TG effort).  There will be a separate TG created to focus on the "M" platform (under a new name).  Philipp and Kumar will be driving setting that up and will be interested to talk with you.

Greg

P.S. This email list also needs to be replaced by a set of lists (for the HSC and for each new SIG/TG), with appropriate new naming of each list.


On Mon, Feb 7, 2022 at 10:26 AM Chris Owen <Chris.Owen@...> wrote:
Hi all,

I lead the CPU software / SDK team at Imagination Technologies, we are entering the RISC-V space but I'm still quite new around here.

At present we are most interested in embedded applications and I am particularly interested in standardising platform aspects in this area.  For example, a Hardware Adaption Layer for bare-metal apps.  I realise, though, that the M platform is rather on hold and all the focus is on OS-A.

Is this the only mailing list for the Platforms HSC?  Or is there another one which could be used for discussions around the M platform?  I realise the title for this list says its for unix-class, but I didn't see any other...

I was just wondering if we could start progressing M platform in parallel with OS-A.  My team and I are ready and willing to engage in this area.  I believe people like SiFive and AliBaba have done lots of work in this area and it would be great to bring them together and standardise rather than allowing things to fragment further.

Thanks for any help and advice,
Chris Owen


Possible progress on M Platform?

Chris Owen
 

Hi all,

I lead the CPU software / SDK team at Imagination Technologies, we are entering the RISC-V space but I'm still quite new around here.

At present we are most interested in embedded applications and I am particularly interested in standardising platform aspects in this area.  For example, a Hardware Adaption Layer for bare-metal apps.  I realise, though, that the M platform is rather on hold and all the focus is on OS-A.

Is this the only mailing list for the Platforms HSC?  Or is there another one which could be used for discussions around the M platform?  I realise the title for this list says its for unix-class, but I didn't see any other...

I was just wondering if we could start progressing M platform in parallel with OS-A.  My team and I are ready and willing to engage in this area.  I believe people like SiFive and AliBaba have done lots of work in this area and it would be great to bring them together and standardise rather than allowing things to fragment further.

Thanks for any help and advice,
Chris Owen


Re: [PATCH] UEFI: Add RISCV_EFI_BOOT_PROTOCOL requirement

Heinrich Schuchardt
 

On 1/31/22 08:43, Sunil V L wrote:
RISC-V UEFI systems need to support new RISCV_BOOT_PROTOCOL.
nits:
%s/RISCV_BOOT_PROTOCOL/RISCV_EFI_BOOT_PROTOCOL/

This protocol is required to communicate the boot hart ID
from firmware to the bootloader/kernel.
This protocol specification is maintained by RVI outside of the UEFI
forum. The latest specification is available at
https://github.com/riscv-non-isa/riscv-uefi/releases/download/1.0-rc2/RISCV_UEFI_PROTOCOL-spec.pdf
Signed-off-by: Sunil V L <sunilvl@...>
This new protocol is needed because ACPI cannot make use of the current device-tree based approach to transfer the boot hart ID to the next boot stage.

The protocol has been implemented in upstream U-Boot (v2022.04-rc1, patch by Sunil).

Acked-by: Heinrich Schuchardt <heinrich.schuchardt@...>

---
riscv-platform-spec.adoc | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 6264ab8..a7f5d92 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -556,6 +556,17 @@ in SBI PMU extensions.
the requirements in this section.
==== Firmware
+===== UEFI Protocol Support
+The UEFI protocols listed below are required to be implemented in addition to
+the requirements in EBBR.
+
+.Additional UEFI Protocols
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI Section | Note
+|RISCV_EFI_BOOT_PROTOCOL | <<spec_riscv_uefi>> | To pass boot hart ID
+|===
+
===== Storage and Partitioning
- GPT partitioning required for shared storage.
- MBR support is not required.
@@ -675,11 +686,12 @@ newer with HW-Reduced ACPI model.
The UEFI protocols listed below are required to be implemented.
.Additional UEFI Protocols
-[cols="3,1,1", width=95%, align="center", options="header"]
+[cols="3,1,2", width=95%, align="center", options="header"]
|===
|Protocol | UEFI Section | Note
|EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL | 14 | For PCIe support
|EFI_PCI_IO_PROTOCOL | 14.4 | For PCIe support
+|RISCV_EFI_BOOT_PROTOCOL | <<spec_riscv_uefi>> | To pass boot hart ID
|===
==== Hardware Discovery Mechanisms
@@ -1102,3 +1114,4 @@ implementations should aim for supporting at least 16 PMP regions.
* [[[spec_riscv_watchdog,22]]] link:https://github.com/riscv-non-isa/riscv-watchdog/blob/main/riscv-watchdog.adoc[RISC-V Watchdog Timer Specification], Version: Version 1.0
* [[[spec_riscv_platform_policy,23]]] link:https://docs.google.com/document/d/1U5qLoztZpCRSnw2s8tx4rB0SFPMQ27Svrr9jWRsOziY/edit[RISC-V Platform Platform Policy], Version: 1.0
* [[[spec_pcie_sig,24]]] link:https://pcisig.com/specifications[PCIe Base Specification Revision], Revision: 1.1
+* [[[spec_riscv_uefi,25]]] link:https://github.com/riscv-non-isa/riscv-uefi/releases/download/1.0-rc2/RISCV_UEFI_PROTOCOL-spec.pdf[RISC-V UEFI Protocol Specification], Version: 1.0-rc2


Configuration Structure Review

Tim Newsome
 

Hi all!

I just sent this to tech-chairs, but due to the nature of your work Stephano suggested getting feedback here as well.

The Configuration Structure task group has been working on how software can determine the capabilities/configuration of the hardware it is running on. At long last we have something that is ready for wider review. (Few people spend time in tech-config regularly, so just a few people have really read this spec so far. There might still be some glaring holes.)

Please take some time to read and review https://github.com/riscv/configuration-structure/blob/master/riscv-configuration-structure-draft.adoc (3200 words). I'm looking forward to your feedback so we can make the spec better, and hopefully freeze it in a few weeks.

Thank you,
Tim


[PATCH] UEFI: Add RISCV_EFI_BOOT_PROTOCOL requirement

Sunil V L
 

RISC-V UEFI systems need to support new RISCV_BOOT_PROTOCOL.
This protocol is required to communicate the boot hart ID
from firmware to the bootloader/kernel.

This protocol specification is maintained by RVI outside of the UEFI
forum. The latest specification is available at
https://github.com/riscv-non-isa/riscv-uefi/releases/download/1.0-rc2/RISCV_UEFI_PROTOCOL-spec.pdf

Signed-off-by: Sunil V L <sunilvl@...>
---
riscv-platform-spec.adoc | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 6264ab8..a7f5d92 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -556,6 +556,17 @@ in SBI PMU extensions.
the requirements in this section.

==== Firmware
+===== UEFI Protocol Support
+The UEFI protocols listed below are required to be implemented in addition to
+the requirements in EBBR.
+
+.Additional UEFI Protocols
+[cols="3,1,2", width=95%, align="center", options="header"]
+|===
+|Protocol | UEFI Section | Note
+|RISCV_EFI_BOOT_PROTOCOL | <<spec_riscv_uefi>> | To pass boot hart ID
+|===
+
===== Storage and Partitioning
- GPT partitioning required for shared storage.
- MBR support is not required.
@@ -675,11 +686,12 @@ newer with HW-Reduced ACPI model.
The UEFI protocols listed below are required to be implemented.

.Additional UEFI Protocols
-[cols="3,1,1", width=95%, align="center", options="header"]
+[cols="3,1,2", width=95%, align="center", options="header"]
|===
|Protocol | UEFI Section | Note
|EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL | 14 | For PCIe support
|EFI_PCI_IO_PROTOCOL | 14.4 | For PCIe support
+|RISCV_EFI_BOOT_PROTOCOL | <<spec_riscv_uefi>> | To pass boot hart ID
|===

==== Hardware Discovery Mechanisms
@@ -1102,3 +1114,4 @@ implementations should aim for supporting at least 16 PMP regions.
* [[[spec_riscv_watchdog,22]]] link:https://github.com/riscv-non-isa/riscv-watchdog/blob/main/riscv-watchdog.adoc[RISC-V Watchdog Timer Specification], Version: Version 1.0
* [[[spec_riscv_platform_policy,23]]] link:https://docs.google.com/document/d/1U5qLoztZpCRSnw2s8tx4rB0SFPMQ27Svrr9jWRsOziY/edit[RISC-V Platform Platform Policy], Version: 1.0
* [[[spec_pcie_sig,24]]] link:https://pcisig.com/specifications[PCIe Base Specification Revision], Revision: 1.1
+* [[[spec_riscv_uefi,25]]] link:https://github.com/riscv-non-isa/riscv-uefi/releases/download/1.0-rc2/RISCV_UEFI_PROTOCOL-spec.pdf[RISC-V UEFI Protocol Specification], Version: 1.0-rc2
--
2.25.1


Re: Public review of Supervisor Binary Interface (SBI) Specification

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


Re: Public review of Supervisor Binary Interface (SBI) Specification

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


Re: Public review of Supervisor Binary Interface (SBI) Specification

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


Introduction Update and OS-A Motivation

Aaron Durbin
 

Hi All,

I submitted a pull request to the platform spec repo: https://github.com/riscv/riscv-platform-specs/pull/75 This is definitely a WIP, but I wanted to start the conversation. Much of the language is cribbed from the platform policy doc itself as I think that was well written and provides the context for the platforms themselves.

Note: there are definitely some other reorganizations required, I think, to make the first part flow better. I was thinking that under the OS-A part specifically we expand further, but I put in a quick blurb to describe that direction.

All that said, there are definitely pieces in the spec that read more like a one pager for product requirements. It's not abundantly clear to me what the platform specs are supposed to be in the end. Are they hardware product requirements or a target of expectations for a software environment? I know this question is a much broader topic, but it's something we should agree on. My personal opinion is that we focus on bootstrapping the software ecosystem so that off the shelf OSes can be used for system evaluation. From there, and once a richer hardware ecosystem is realized, I can definitely see the platform specs turning more into a hardware product requirements.

Lastly, feel free to pepper me with suggestions on how to take the language. I can play secretary on everyone's behalf.

Thanks. 

-Aaron

161 - 180 of 1845