On Tue, 2020-09-01 at 17:10 +0800, Bin Meng wrote:

Hi Anup,

On Tue, Sep 1, 2020 at 4:40 PM Anup Patel <anup.patel@...> wrote:

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.

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?

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 been
in discussion for more than a year now.

Regards,
Bin

--
Regards,
Atish