Hi All,

Two solutions were discussed at LPC2020 for RISC-V S-mode system
reset mechanism.
(Slides, https://linuxplumbersconf.org/event/7/contributions/810/attachments/631/1144/RISCV_EBBR_lpc2020.pdf)

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
(https://lists.riscv.org/g/tech-unixplatformspec/message/49)
* 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
approach because:
* 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.

Regards,
Anup