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.

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.

Regards,
Bin