Date   

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


Re: Specifying Cache Granule Size in Platform

mark
 

Are we or will we be using any benchmarks here?

I worry that this is based on experience. Workloads have evolved.

Things like traversing workloads (hadoop, cpu encrypt, cpu compress, ...) and sparse workloads (uniq query hash tables, sparse matrices, ...) have many times become more important than the principles of locality.

I know we are just starting the perf modeling sig but I suggest we will have to settle on a tool we use to identify issues and mark progress over an agreed set of cache/memory configurations. Of course vendors will test on their hardware. While I understand some basics are just needed, when I hear David talk in his comments I suggest we pick ways to grade ourselves and our choices objectively.

In my experience getting these things wrong (locks and latches, cache prefetch, cache fragmentation, cache occupancy, etc.) can easily exceed any benefit we get from instruction architecture improvements.

These issues cross many group boundaries.

Mark

On Mon, Jan 24, 2022 at 10:28 PM David Kruckemyer <dkruckemyer@...> wrote:
Hi all,

A few comments to add on here:

- The expectation in the CMO group was that there *could* be different cache block sizes for different operations. As Aaron points out, one may have one block size for Zicboz instructions, and another for Zicbom instructions (and maybe even another for Zicbop instructions, too).
- v1.0 of these specs requires that the block size is fixed across the system
- The block size is discoverable via to-be-specified standard discovery structure, but the thinking was that software at all privilege levels could access that information (though such information may be virtualized as necessary)
- Though not formally specified (yet), the working definition of "cache block" is the NAPOT region that a CMO instruction operates on, independent of the implemented cache line size; so in some sense, a cache block abstracts away cache lines. As I mentioned, that's a working definition, and there are of course issues that arise when there is a mismatch between the abstract block size and the actual line size (and one of the items on the to-do list for the CMO TG is to address some of these issues). Anyway, the key takeaway is that the terminology for block, line, granule, etc. should be well-defined, and the platform group and the CMO TG should align.
- Note that there is often a close relationship between the cache line size and the coherence granule size (I know, introducing a new term here), and though this may not be the right forum for the discussion, the architecture needs to understand whether different line sizes implies different coherence granule sizes (or more generally, whether one implies constraints on the other).
- Another related issue is LR/SC reservation set size.
- Philosophical thought: Trap and emulate allows one to commit a bunch of sins, and it may be pragmatic for certain platform definitions to be performant only for "common" implementations and to just be compatible for other implementations. For example, the block size for CBO.ZERO could be defined to be 64B in a platform. On harts that support 64B zero writes, executing CBO.ZERO performs the operation without a trap; on harts that do not, executing CBO.ZERO traps to a handler that performs the equivalent of the 64B zero write. (The trapping behavior can be controlled by xenvcfg.CBZE.)

That was a bit more than I expected to write. Hope some of it is helpful....

Cheers,
David


On Mon, Jan 24, 2022 at 7:15 PM Aaron Durbin <adurbin@...> wrote:
Hi All,

During the Platform HSC the topic of specifying an expected cache granule size for a platform was brought up. Below are some thoughts/observations on the topic. The purpose of this email is to provide a basis for discussion. 

Philip indicated cbo.zero would be the main target for specifying the size. If we went down that path, I think it'd be important to also specify the size for cbo.flush as well.

If the granule size is only determined at run time there inherently are solutions that need to be constructed to deal with a number of scenarios. Some cases to think about:

1. Userland drivers
2. VM migration
3. object layout in memory for optimization purposes
4. inconsistent granule size within different harts in the system

Ved brought up how it's important to interrogate the cache hierarchy for these attributes, and that it's important to know on a per-hart basis what cache granule size it deals with.

We can certainly engineer solutions for the various cases in either scenario, but I think the discussion around specifying the granule size should be in understanding how we'd deal with those solutions going forward. And please offer any other scenarios that may come to mind. Lastly, I apologize if I missed any particular commentary on this subject. 

Thanks.

-Aaron


Re: Specifying Cache Granule Size in Platform

David Kruckemyer
 

Hi all,

A few comments to add on here:

- The expectation in the CMO group was that there *could* be different cache block sizes for different operations. As Aaron points out, one may have one block size for Zicboz instructions, and another for Zicbom instructions (and maybe even another for Zicbop instructions, too).
- v1.0 of these specs requires that the block size is fixed across the system
- The block size is discoverable via to-be-specified standard discovery structure, but the thinking was that software at all privilege levels could access that information (though such information may be virtualized as necessary)
- Though not formally specified (yet), the working definition of "cache block" is the NAPOT region that a CMO instruction operates on, independent of the implemented cache line size; so in some sense, a cache block abstracts away cache lines. As I mentioned, that's a working definition, and there are of course issues that arise when there is a mismatch between the abstract block size and the actual line size (and one of the items on the to-do list for the CMO TG is to address some of these issues). Anyway, the key takeaway is that the terminology for block, line, granule, etc. should be well-defined, and the platform group and the CMO TG should align.
- Note that there is often a close relationship between the cache line size and the coherence granule size (I know, introducing a new term here), and though this may not be the right forum for the discussion, the architecture needs to understand whether different line sizes implies different coherence granule sizes (or more generally, whether one implies constraints on the other).
- Another related issue is LR/SC reservation set size.
- Philosophical thought: Trap and emulate allows one to commit a bunch of sins, and it may be pragmatic for certain platform definitions to be performant only for "common" implementations and to just be compatible for other implementations. For example, the block size for CBO.ZERO could be defined to be 64B in a platform. On harts that support 64B zero writes, executing CBO.ZERO performs the operation without a trap; on harts that do not, executing CBO.ZERO traps to a handler that performs the equivalent of the 64B zero write. (The trapping behavior can be controlled by xenvcfg.CBZE.)

That was a bit more than I expected to write. Hope some of it is helpful....

Cheers,
David


On Mon, Jan 24, 2022 at 7:15 PM Aaron Durbin <adurbin@...> wrote:
Hi All,

During the Platform HSC the topic of specifying an expected cache granule size for a platform was brought up. Below are some thoughts/observations on the topic. The purpose of this email is to provide a basis for discussion. 

Philip indicated cbo.zero would be the main target for specifying the size. If we went down that path, I think it'd be important to also specify the size for cbo.flush as well.

If the granule size is only determined at run time there inherently are solutions that need to be constructed to deal with a number of scenarios. Some cases to think about:

1. Userland drivers
2. VM migration
3. object layout in memory for optimization purposes
4. inconsistent granule size within different harts in the system

Ved brought up how it's important to interrogate the cache hierarchy for these attributes, and that it's important to know on a per-hart basis what cache granule size it deals with.

We can certainly engineer solutions for the various cases in either scenario, but I think the discussion around specifying the granule size should be in understanding how we'd deal with those solutions going forward. And please offer any other scenarios that may come to mind. Lastly, I apologize if I missed any particular commentary on this subject. 

Thanks.

-Aaron


Specifying Cache Granule Size in Platform

Aaron Durbin
 

Hi All,

During the Platform HSC the topic of specifying an expected cache granule size for a platform was brought up. Below are some thoughts/observations on the topic. The purpose of this email is to provide a basis for discussion. 

Philip indicated cbo.zero would be the main target for specifying the size. If we went down that path, I think it'd be important to also specify the size for cbo.flush as well.

If the granule size is only determined at run time there inherently are solutions that need to be constructed to deal with a number of scenarios. Some cases to think about:

1. Userland drivers
2. VM migration
3. object layout in memory for optimization purposes
4. inconsistent granule size within different harts in the system

Ved brought up how it's important to interrogate the cache hierarchy for these attributes, and that it's important to know on a per-hart basis what cache granule size it deals with.

We can certainly engineer solutions for the various cases in either scenario, but I think the discussion around specifying the granule size should be in understanding how we'd deal with those solutions going forward. And please offer any other scenarios that may come to mind. Lastly, I apologize if I missed any particular commentary on this subject. 

Thanks.

-Aaron


Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs

Greg Favor
 

On Mon, Jan 24, 2022 at 10:32 AM Michael Frank <Michael.Frank@...> wrote:
Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each profile?

The RVA22S64 ISA profile will provide all that detail.  An 2022 OS-A platform spec will simply mandate the RVA22S64 profile.

Greg 


Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs

Michael Frank
 

Hi Greg,
Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each profile?

Michael



😄
Michael


From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...>
Sent: Monday, January 24, 2022 7:59:22 AM
To: tech-unixplatformspec <tech-unixplatformspec@...>
Cc: Greg Favor <gfavor@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] Mandating of RVA22 S and U ISA Profiles in OS-A platform specs
 

[EXTERNAL EMAIL]

On Mon, Jan 24, 2022 at 6:45 AM Darius Rad <darius@...> wrote:
> Recently a PR was sent out to remove U and VU mode standardization from the
> platform spec scope.  Which is sort of right and sort of wrong.

Could you explain in what way you think it is wrong?

That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA functionality through its profile mandate.

> *The current version of this platform spec targets the standardization of
> functionality available in S and VS modes (plus the support for U/VU-modes,
> and the support for ISA extensions in U/VU modes, as implied by the RVA 'S'
> ISA Profile that is mandated by this spec), and the standardization of the
> SBI (....).*
>

I disagree; I think the parenthetical comment is unnecessary in the
normative text.

I viewed the text in question as simply describing the standardization scope of the platform spec in saying what it is targeting (versus all the actual normative mandates in the platform spec).  One can view the text as also truly a normative part of the spec, or simply as descriptive overview of the scope of the normative spec.

In any case, one can certainly view the parenthetical comment as non-normative information to the reader of the spec that points out that even though the spec appears to only specify S/VS-mode functionality, it actually also specifies U/VU-mode functionality.  Not mentioning this (non-normatively) is just "hiding the ball" from the reader and expecting all readers to realize what's really going on as far as indirect specification of U/VU-mode functionality.
 
The first portion is explicit in the privileged specification, and the
second portion, and noted, is implied by the extensions mandated for S
mode.  Adding this comment as normative text muddies the scope of the
specification: it is standardizing the S-mode interface only.  Period.

But that's the point. The platform spec is, indirectly, specifying U/VU-mode functionality.

But I agree that the above parenthetical comment is non-normative information that just helps the reader to realize that more than S/VS-mode is effectively being standardized by the spec.  If one views the scope statement as a normative mandate of the platform spec (instead of just a descriptive overview), then certainly the parenthetical text should be separated out as a non-normative comment.

Lastly, I'll note that the software ecosystem cares about what IS being mandated by the OS-A platform spec regarding U/VU-mode ISA functionality.  Since the target of the platform is to support hardware/software interoperability with binary distros, those distros (e.g. Linux) contain U/VU-mode code.  Put differently, a Linux distro depends on standardization of ISA functionality at both S/VS and U/VU modes.  Saying that the platform spec only standardizes the S-mode interface can be misleading to readers.  It standardizes lots of S/VS-mode hardware and software functionality, and (indirectly) also standardizes U/VU-mode ISA functionality.

Greg

To reduce fraud or cyber-crime risks, Arteris IP will never instruct you to change wire payment instructions or bank account details using email or fax. If you receive such an email or fax appearing to be from Arteris IP, please call your Arteris IP’s contact to verify. Please do not verify by email.


Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs

Greg Favor
 

On Mon, Jan 24, 2022 at 6:45 AM Darius Rad <darius@...> wrote:
> Recently a PR was sent out to remove U and VU mode standardization from the
> platform spec scope.  Which is sort of right and sort of wrong.

Could you explain in what way you think it is wrong?

That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA functionality through its profile mandate.

> *The current version of this platform spec targets the standardization of
> functionality available in S and VS modes (plus the support for U/VU-modes,
> and the support for ISA extensions in U/VU modes, as implied by the RVA 'S'
> ISA Profile that is mandated by this spec), and the standardization of the
> SBI (....).*
>

I disagree; I think the parenthetical comment is unnecessary in the
normative text.

I viewed the text in question as simply describing the standardization scope of the platform spec in saying what it is targeting (versus all the actual normative mandates in the platform spec).  One can view the text as also truly a normative part of the spec, or simply as descriptive overview of the scope of the normative spec.

In any case, one can certainly view the parenthetical comment as non-normative information to the reader of the spec that points out that even though the spec appears to only specify S/VS-mode functionality, it actually also specifies U/VU-mode functionality.  Not mentioning this (non-normatively) is just "hiding the ball" from the reader and expecting all readers to realize what's really going on as far as indirect specification of U/VU-mode functionality.
 
The first portion is explicit in the privileged specification, and the
second portion, and noted, is implied by the extensions mandated for S
mode.  Adding this comment as normative text muddies the scope of the
specification: it is standardizing the S-mode interface only.  Period.

But that's the point. The platform spec is, indirectly, specifying U/VU-mode functionality.

But I agree that the above parenthetical comment is non-normative information that just helps the reader to realize that more than S/VS-mode is effectively being standardized by the spec.  If one views the scope statement as a normative mandate of the platform spec (instead of just a descriptive overview), then certainly the parenthetical text should be separated out as a non-normative comment.

Lastly, I'll note that the software ecosystem cares about what IS being mandated by the OS-A platform spec regarding U/VU-mode ISA functionality.  Since the target of the platform is to support hardware/software interoperability with binary distros, those distros (e.g. Linux) contain U/VU-mode code.  Put differently, a Linux distro depends on standardization of ISA functionality at both S/VS and U/VU modes.  Saying that the platform spec only standardizes the S-mode interface can be misleading to readers.  It standardizes lots of S/VS-mode hardware and software functionality, and (indirectly) also standardizes U/VU-mode ISA functionality.

Greg


Re: Mandating of RVA22 S and U ISA Profiles in OS-A platform specs

Darius Rad
 

On Sat, Jan 22, 2022 at 12:15:01PM -0800, Greg Favor wrote:

Recently a PR was sent out to remove U and VU mode standardization from the
platform spec scope. Which is sort of right and sort of wrong.
Could you explain in what way you think it is wrong?

I brought this issue up with Krste and Andrew (especially since this also
relates with the coming RVA Profiles). In short, after significant
discussion, the following can be said:

- Support for the RVA22S64 profile does not directly also require
support for the RVA22U64 profile. Although it does require support for
U-mode.

- BUT, for example, all mandatory ISA extensions in the 'S' profile that
are also in the 'U' profile must be supported not only in S-mode but also
in U-mode. This only excludes ISA extensions that are not relevant to
U-mode, e.g. the Sstc extension. Largely, if not completely, this amounts
to all Unpriv ISA extensions that are required to be supported in S-mode
are also required to be supported in U-mode. The Profile specs will
precisely spell out this and the related matter of "optional supported"
extensions.

- The OS-A platforms should only mandate the RVA22S64 profile (and not
the RVA22U64 profile as well). U/VU-mode platform requirements will
flow from or be indirectly inherited via the RVA22S64
profile requirement.


So I suggest that the change to the platform spec should be something like:

*The current version of this platform spec targets the standardization of
functionality available in S and VS modes (plus the support for U/VU-modes,
and the support for ISA extensions in U/VU modes, as implied by the RVA 'S'
ISA Profile that is mandated by this spec), and the standardization of the
SBI (....).*
I disagree; I think the parenthetical comment is unnecessary in the
normative text.

The first portion is explicit in the privileged specification, and the
second portion, and noted, is implied by the extensions mandated for S
mode. Adding this comment as normative text muddies the scope of the
specification: it is standardizing the S-mode interface only. Period.

// darius


Mandating of RVA22 S and U ISA Profiles in OS-A platform specs

Greg Favor
 

All,

Recently a PR was sent out to remove U and VU mode standardization from the platform spec scope.  Which is sort of right and sort of wrong.

I brought this issue up with Krste and Andrew (especially since this also relates with the coming RVA Profiles).  In short, after significant discussion, the following can be said:
  • Support for the RVA22S64 profile does not directly also require support for the RVA22U64 profile.  Although it does require support for U-mode.

  • BUT, for example, all mandatory ISA extensions in the 'S' profile that are also in the 'U' profile must be supported not only in S-mode but also in U-mode.  This only excludes ISA extensions that are not relevant to U-mode, e.g. the Sstc extension.  Largely, if not completely, this amounts to all Unpriv ISA extensions that are required to be supported in S-mode are also required to be supported in U-mode.  The Profile specs will precisely spell out this and the related matter of "optional supported" extensions.

  • The OS-A platforms should only mandate the RVA22S64 profile (and not the RVA22U64 profile as well).  U/VU-mode platform requirements will flow from or be indirectly inherited via the RVA22S64 profile requirement.

So I suggest that the change to the platform spec should be something like:
The current version of this platform spec targets the standardization of functionality available in S and VS modes (plus the support for U/VU-modes, and the support for ISA extensions in U/VU modes, as implied by the RVA 'S' ISA Profile that is mandated by this spec), and the standardization of the SBI (....).

Greg


Next Platform HSC Meeting on Mon Jan 24th 2022 8AM PST

Kumar Sankaran
 

Hi All,
The next platform HSC meeting is scheduled on Mon Jan 24th 2022 at 8AM PST.

Here are the details:

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

Here are the slides:
https://docs.google.com/presentation/d/1fVM2loPrbBotyhiC5JNt0NqkbD3MkRu5-Rr23BCMzo4/edit#slide=id.g1044423f839_0_0

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: Public review of Supervisor Binary Interface (SBI) Specification

merle w
 

Thank you for your reply


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

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


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

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


Re: [PATCH] Remove stoptime requirement

Kumar Sankaran
 

Hi Paul,

Can you send a PR please?

 

Regards

Kumar

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Paul Donahue
Sent: Wednesday, January 12, 2022 11:49 AM
To: tech-unixplatformspec <tech-unixplatformspec@...>
Subject: [RISC-V] [tech-unixplatformspec] [PATCH] Remove stoptime requirement

 

Signed-off-by: Paul Donahue <pdonahue@...>

---
 riscv-platform-spec.adoc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 238af3a..7a02b76 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -261,8 +261,7 @@ and one resume group (in addition to group 0)
 - dcsr.stepie must support the 0 setting. It is optional to support the 1
 setting
   * Rationale: It is not generally useful to step into interrupt handlers.
-- dcsr.stopcount and dcsr.stoptime must be supported and the reset value of
-each must be 1
+- dcsr.stopcount must be supported and the reset value must be 1
   * Rationale: The architecture has strict requirements on minstret which may
     be perturbed by an external debugger in a way that's visible to software.
     The default should allow code that's sensitive to these requirements to be
--
2.21.0


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

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


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

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





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

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





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

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


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

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




181 - 200 of 1847