Hi Abner and Jonathan,

you're right. I included that sentence to give the implementor a way out,
if the spec doesn't cover a particular case. Now I understand that this would
be result in very unpredictable behaviour and invite misuse.
If the spec if broken, we need to fix it.

Has anybody thought about an SBI testing tool to make sure an implementation
conforms to the spec? Should be doable by hooking QEMU.

Here's the updated text:

    Every function defined in the specification has a set of error codes
    associated with a case in which they are returned. In the even of such a
    case, that error code must be returned. No other error code must be returned.

    Custom SBI calls defined in a vendor or firmware extension can return
    custom error codes, however it is recommended that they use the standard
    error codes when appropriate.

Another thought: We've got some uses of 'must', 'should', ... .
Should we add a reference to RFC2199 [1] and check whether we used all of the
keywords correctly?

[1] https://tools.ietf.org/html/rfc2119

- Daniel

On 5/18/20 3:42 AM, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Daniel,

It is no necessary to mention that sentence, instead we should well define the error codes returned from all sbi function, as you said no more, no less.

that says we shouldn’t have unaccounted cases with a unclear error code defined in sbi function. The sbi function is not just a guidance to sbi implementation, it could be also a criteria for SBI testing tool to validate the error code return from the implementation of sbi function.

Right?

 

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, May 18, 2020 5:56 AM
To: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] SBI Error codes

 

Is it really necessary to include "Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification." ? This empowers an implementation to return ERR_FAILED whenever it doesn't feel like executing a function. In the extreme case, you could have an empty implementation that declared "function unimplemented" to be a case that is unaccounted for by the spec, and just returned failure for literally every call. It also isn't clear to me how a supervisor is meant to respond to getting one of these errors. Should it retry until it gets success? Issue a kernel panic? Something else?

 

Jonathan

 

On Sun, May 17, 2020 at 2:21 PM Daniel Schaefer <daniel.schaefer@...> wrote:

On 5/17/20 5:20 PM, Jonathan Behrens wrote:
> I'd argue that standard functions should only be allowed to return the
> error codes specifically listed in their descriptions (or
> SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier
> for users of the API if they can know in advance what errors could be
> returned. This is the way I interpreted the current spec, though
> clarification might be worthwhile.
>
> Jonathan
>
> On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
>
>     Hi all,
>
>     The SBI spec defines a standard set of error codes, which SBI
>     functions can
>     return in case of failure (or success). Each function defined in the
>     SBI spec
>     also defines which error codes it returns in which cases.
>
>     My question is:
>     Can an SBI implementation deviate from these error codes or do the
>     SBI ecalls
>     have to return the standardized error codes, no more, no less?
>     If they can, in which way? Do they have to implement the standard
>     error codes
>     for the listed cases but can return additional error codes for other
>     non-specified cases?
>
>     I'm talking only about the standardized functions. Functions in the
>     vendor
>     extension and proposed firmware extension could of course do
>     whatever they
>     want.
>
>     Btw. I think we should mention in the riscv-sbi-doc repo, that this
>     ML is the place to discuss SBI.
>     (It is, right?)
>
>     - Daniel

Yes, my thinking, too. I created a PR with my proposed additions to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51

Inline here also:


Every function defined in the specification has a set of error codes
associated with a case in which they are returned. In the even of such a
case, that error code must be returned. Cases unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added in the next
version of the SBI specification.

Custom SBI calls defined in a vendor or firmware extension can return
custom error codes, however it is recommended that they use the standard
error codes when appropriate.

- Daniel