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 theI think there is a lot of confusion here because the discussion does
seem either trivial to solve or seem unimportant for this use case
Anup clearly has a different point of view).
The real issue for us as a group is whether we should be in the
standardizing our own specifications that aren't directly related
when adequate existing specifications already exist.
In the past, we've sought to draw a bright line between RISC-V CPU-
operations, which we've proposed are in the scope of the SBI
"everything else" -- in particular, operations that aren't specific
(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,
seems worth upholding - in line with the broader RISC-V commitments
minimalism and modularity.
separates the semantic and the syntax/implementation of the
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
semantic level. The actual definition of the interface, the syntax
need to be RISC-V specific. And using an SBI call to implement the
an operation defined by PSCI seem like a clean approach to me. That
reinventing the wheel. It is only a different implementation of the
However, if the specification being considered has a semantic that
architecture specific information/state that cannot be mapped onto
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
SBI extensions as the implementation approach would also potentially
reset/shutdown specification to smaller embedded systems too. That
like a very nice property to me, and as such not something we should
outright to allow for reusing an existing specification that may not
scaling (e.g. I do not see UEFI as a good candidate for embedded/RTOS
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.