-----Original Message-----
From: tech-unixplatformspec@... <tech-
unixplatformspec@...> On Behalf Of Bin Meng
Sent: 04 June 2021 15:20
To: Anup Patel <Anup.Patel@...>
Cc: tech-unixplatformspec@...; Atish Patra
<Atish.Patra@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] Add direct memory
access synchronize extension

On Fri, Jun 4, 2021 at 5:33 PM Anup Patel <Anup.Patel@...> wrote:

-----Original Message-----
From: Bin Meng <bmeng.cn@...>
Sent: 04 June 2021 14:50
To: Anup Patel <Anup.Patel@...>
Cc: tech-unixplatformspec@...; Atish Patra
<Atish.Patra@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] Add direct
memory access synchronize extension

On Fri, Jun 4, 2021 at 5:06 PM Anup Patel <Anup.Patel@...> wrote:

-----Original Message-----
From: Bin Meng <bmeng.cn@...>
Sent: 04 June 2021 14:12
To: Anup Patel <Anup.Patel@...>
Cc: tech-unixplatformspec@...; Atish Patra
<Atish.Patra@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] Add direct
memory access synchronize extension

On Fri, Jun 4, 2021 at 4:26 PM Anup Patel <Anup.Patel@...>

wrote:

-----Original Message-----
From: Bin Meng <bmeng.cn@...>
Sent: 04 June 2021 13:07
To: Anup Patel <Anup.Patel@...>
Cc: tech-unixplatformspec@...; Atish Patra
<Atish.Patra@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] Add
direct memory access synchronize extension

On Thu, Jun 3, 2021 at 11:47 PM Anup Patel
<Anup.Patel@...>

wrote:

-----Original Message-----
From: tech-unixplatformspec@... <tech-
unixplatformspec@...> On Behalf Of Bin Meng
Sent: 03 June 2021 21:02
To: Anup Patel <Anup.Patel@...>
Cc: tech-unixplatformspec@...; Atish Patra
<Atish.Patra@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH]
Add direct memory access synchronize extension

On Thu, Jun 3, 2021 at 11:13 PM Anup Patel
<anup.patel@...>

wrote:

This patch adds SBI direct memory access synchronize
(DSYN)) extension which allows S-mode (or VS-mode)
software to explicitly synchronize memory with
assistance from the M-mode (or

HS-mode).

Signed-off-by: Anup Patel <anup.patel@...>
---
riscv-sbi.adoc | 95

++++++++++++++++++++++++++++++++++++++++++++++++++

1 file changed, 95 insertions(+)

diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index
79d98a6..0eb2898
100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -27,6 +27,10 @@

https://creativecommons.org/licenses/by/4.0/.

[preface]
== Change Log

+=== Version 0.4-rc0

What's our policy of bumping up versions?

This extension is meant for SBI v0.4 based on discussion with

Atish.

We will be soon freezing SBI v0.3.

Do we have policies, or planning/schedule of versions?

We have not documented a detailed policy/plan/schedule for all
SBI spec versions.

What is the version supposed to be used for?

The set of functions (or definition of functions) provided by
a SBI extension can change over time so the SBI spec version
helps us differentiate this changes.

For example, SBI HSM extension defined in SBI v0.2 does not
include SBI HSM suspend call but the v0.3 does include SBI HSM
suspend call so the Linux CPUIDLE driver will check both SBI
spec version and availability of SBI HSM extension before
using SBI HSM

suspend call.

Any function not supported, OS can make the SBI call, and check
its return value against SBI_ERR_NOT_SUPPORTED. I don't believe
an arbitrary version number really helps here.

We can't blindly call a SBI function just to check if it is present or not.

For example, the SBI HSM suspend call will suspend the current CPU
and the CPU will not resume until some interrupt/resume event

happens.

If CPU is successfully suspended, then the function is implemented
by SBI firmware. I don't see why I need to care about the version number.
If suspend function is not available, then SBI_ERR_NOT_SUPPORTED is
returned.

That's why we need to use combination of SBI spec version and SBI
probe extension to know whether a particular SBI function is
available or not.

I would like to re-iterate that SBI extensions as whole are
optional but if a SBI <abc> extension compliant with SBI v0.X spec
is implemented then all functions of SBI <abc> extension as
defined in SBI v0.X are assumed to be present. Basically, a SBI
extension cannot be partially implemented.

Is this clearly documented?

Argh, this should have been documented in the introduction chapter.

I can send a patch.

Yes, please go ahead.

Also, newly defined SBI extensions won't be available on
firmware implementing older SBI spec version so S-mode
software should always probe SBI extensions based on SBI spec

version.

For example, SBI SRST extension will be available in only in
firmware implementing SBI v0.3 or higher.

Like you said, SRST extension can be probed. The version number
is not needed.

Checking both SBI spec version before doing SBI probe helps us
avoid unnecessary SBI probe.

Then why did we invent the probe function in the first place? We can
rely on SBI version anyway and maintain a big function matrix in the
OS, but as we introduce more and more extensions over time, I don't

think that's scalable.

Checking SBI spec version before doing SBI probe does not help much
compared to a simple probe without caring about version number.

SBI spec = calling convention + a set of SBI extension

SBI extension = a set of SBI functions

We have the SBI extension probing in SBI spec so that SBI
implementation can skip SBI extension for which some other HW

mechanism is available.

For example, SBI TIMER extension is not required when underlying HW
has RISC-V Sstc extension proposed by Greg

I know probe() can be helpful. I just don't see the value of using version
number to determine whether a certain SBI extension is avaiable.

Yes, using probe() along with spec version can only helps us save
few probe falls. Checking spec version is certainly not mandatory.

Regards,
Anup

Regards,
Bin