On Mon, 2020-05-18 at 14:05 +0200, Schaefer, Daniel Helmut (DualStudy) wrote: 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.
Yeah. That would be useful. Patches are welcome!! 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.
As discussed in the OpenSBI mailing list, this might not be possible always. Supervisor software should decide whether it wants to hang the system or continue in case of an unknown error (i.e. SBI_ERR_FAILED). 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
Yup. That would be nice. - 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 -- Regards, Atish
|
