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

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?

We should conclude SBI RESET extension soon because it has been
in discussion for more than a year now.

Regards,
Bin

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

On Tue, 2020-09-01 at 08:40 +0000, 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.

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

Regards,
Anup

--
Regards,
Atish

My opinion on this hasn't changed for the past year or two:  we should avoid reinventing the wheel:

https://lists.riscv.org/g/tech-unixplatformspec/message/226

- Paul