Date 1 - 5 of 5
Standard system reset mechanism for RISC-V S-mode
Two solutions were discussed at LPC2020 for RISC-V S-mode system
Solution1: Platform and Hypervisor specific reset mechanism
* Every hypervisors will have to emulate their own MMIO device
(or SBI call) for system reset
* U-Boot has CONFIG_SYSRESET that can be overridden for individual
platforms (and hypervisors)
* All UEFI implementations (EDK2) have to carry platform (and
hypervisor) specific reset code
* No way to authenticate system reset from non-secure OS
Solution2: SBI RESET extension
* Already under review
* System reset via standard SBI interface
* Standard mechanism for all hypervisors to provide system reset
* Allows supervisors to use the same interface for system reset
* System reset request from a non-secure OS authenticated via
secure monitor running in M-mode
* SBI RESET extension is optional and platforms can define
non-standard platform specific RESET mechanism
* EFI_RESET_SYSTEM implementation can fallback to platform
RESET if SBI RESET is not available
Almost everyone at LPC2020 agreed that we certainly need a standard
reset mechanism for RISC-V S-mode. This means Solution1 is not the
right way forward.
It was suggested to emulate ARM PSCI SYSTEM_RESET as a SBI call
instead of defining SBI RESET extension. This is not a suitable
* The RISC-V SBI calling convention is very different from the
ARM PSCI calling convention.
* The ARM PSCI defines separate calls for system power-off,
cold-reboot, and warm-reboot whereas the SBI RESET extension
proposes only one SBI call to achieve system power-off,
cold-reboot, and warm-reboot. The SBI RESET extension also
has provision for vendor-specific reset types.
* Lot of ARM PSCI calls take ARM specific power-states and
multi-process affinity levels as parameters so the ARM PSCI
spec is indeed very ARM specific and not suitable for RISC-V.
In past, it was suggested that we restrict SBI spec to HART-level
calls and avoid system-level calls (such as SBI RESET extension).
The SBI spec already has system-level calls such as SBI IPI/RFENCE
calls. A SBI IPI call on HART X can inject software interrupt on some
other HART Y so clearly the SBI IPI call affects multiple HARTs hence
it is a system-level call. In future, we will be having important
system-level para-virt SBI calls for hypervisors to address problems
such as CPU steal time accounting and Guest migration time scaling.
Please provide suggestions/feedback/objections for Solution2.
We should conclude SBI RESET extension soon because it has been
in discussion for more than a year now.
On Tue, Sep 1, 2020 at 4:40 PM Anup Patel <anup.patel@...> wrote:
If we go for solution 2, S-mode software is still able to issue reset
the whole system directly using CONFIG_SYSRESET sort of drivers. Is
this an expected use case?
On Tue, 2020-09-01 at 17:10 +0800, Bin Meng wrote:
Hi Anup,SBI RESET extension is optional. So S-mode software can always fallback
on CONFIG_SYSREST to reset the system.
--We should conclude SBI RESET extension soon because it has beenRegards,
On Tue, 2020-09-01 at 08:40 +0000, Anup Patel wrote:
Hi All,+ Paul/Palmer
Any other comments/suggestions ? It would be great if we conclude
either way and have some standard reset mechanism sooner than later.
We should conclude SBI RESET extension soon because it has been--
My opinion on this hasn't changed for the past year or two: we should avoid reinventing the wheel:
On 9/3/20 10:27 AM, Atish Patra wrote:
+ Paul/Palmer Any other comments/suggestions ? It would be great if we conclude either way and have some standard reset mechanism sooner than later.
|1 - 5 of 5|