On Thu, 2020-09-10 at 22:47 +0000, Damien Le Moal wrote:

On 2020/09/11 1:30, Paul Walmsley wrote:

The core issue here isn't a technical one, I think. All of the
technical issues
seem either trivial to solve or seem unimportant for this use case
(although
Anup clearly has a different point of view).


The real issue for us as a group is whether we should be in the
business of
standardizing our own specifications that aren't directly related
to RISC-V,
when adequate existing specifications already exist.


In the past, we've sought to draw a bright line between RISC-V CPU-
related
operations, which we've proposed are in the scope of the SBI
standard; and
"everything else" -- in particular, operations that aren't specific
to RISC-V
(of which reset, shutdown, and system suspend are clear examples).
As a group,
we haven't always done the best job here. The core principle,
nevertheless,
seems worth upholding - in line with the broader RISC-V commitments
to
minimalism and modularity.

I think there is a lot of confusion here because the discussion does
not
separates the semantic and the syntax/implementation of the
specifications.
Reusing the *semantic* defined elsewhere by existing standards such
as Arm PSCI
seems like a goo idea to me, since yes, that indeed *could* simplify
implementation. But most likely that's it. We have to stop there, at
the
semantic level. The actual definition of the interface, the syntax
part, will
need to be RISC-V specific. And using an SBI call to implement the
semantic of
an operation defined by PSCI seem like a clean approach to me. That
is not
reinventing the wheel. It is only a different implementation of the
same thing.

However, if the specification being considered has a semantic that
depends on
architecture specific information/state that cannot be mapped onto
RISC-V, that
that specification is out. We cannot reuse it. Arm PSCI sound like
such a thing
and that is I think Anup's opinion.

UEFI may be more generic, but I will refrain from commenting further
as I would
need to dive into the specs first to check.

While we are here in the context of "Unix" specifications, rich-OS
level, using
SBI extensions as the implementation approach would also potentially
scale the
reset/shutdown specification to smaller embedded systems too. That
does sound
like a very nice property to me, and as such not something we should
dismiss
outright to allow for reusing an existing specification that may not
allow this
scaling (e.g. I do not see UEFI as a good candidate for embedded/RTOS
systems...).

I agree. Let's keep UEFI out of this discussion as UEFI support can't
be mandatory on all platforms. Moreover, UEFI runtime services are
implemented between same privilege levels. Thus, UEFI reset would work
between Rich "OS"(Linux, Windows, BSDs..) and UEFI service provider (U-
Boot & EDK2).

The standard RESET mechanism can be used by UEFI provider to actually
call into M-mode. Rich "OS" running in S-mode also need to implement
the standard RESET method in case UEFI reset service is not available.

--
Regards,
Atish