On Tue, 2020-09-01 at 17:10 +0800, Bin Meng wrote:
On Tue, Sep 1, 2020 at 4:40 PM Anup Patel <anup.patel@...> wrote:
Hi All,If we go for solution 2, S-mode software is still able to issue reset
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
other HART Y so clearly the SBI IPI call affects multiple HARTs
it is a system-level call. In future, we will be having important
system-level para-virt SBI calls for hypervisors to address
such as CPU steal time accounting and Guest migration time scaling.
Please provide suggestions/feedback/objections for Solution2.
the whole system directly using CONFIG_SYSRESET sort of drivers. Is
this an expected use case?
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,
in discussion for more than a year now.