Closed glikely closed 6 years ago
Rework text to account for RebootSystem() might fail, and OS should fail-over to platform specific method -- PSCI on aarch64
Current proposed patch says to prefer PSCI over UEFI ResetSystem(). After discussion, this may be problematic because it requires the board vendor to touch Trusted Firmware to tap the right thing on shutdown of the system. Shift back to preferring UEFI interface?
Need some commentary in EBBR as to why this is the suggestion. Default implementation will be to simply make the PSCI call in ResetSystem()
I'll take the action to rework the patch to go back to UEFI preferred.
I do not intend to derail the thread here. I just have a related but basic question. As per my understanding, PSCI should be implemented in EL0 mode. While UEFI interface should be implemented in EL1 or EL2.
As EBBR is heavily reliant UEFI interface, does it mean that EBBR interface will also be implemented in EL1 or EL2 only ? or EBBR interface will act as a bridge between PSCI (EL0) and EL1/2 mode.
Hi Atish
I think you have some of the exception level's confused (EL0 without a prefix is non-secure userspace). Similarly the discussion here is not about the creation of an "EBBR interface" it only about which of the two available reset interfaces (PSCI and EFI) is preferred (which one the OS shall try first if both interfaces are provided).
Note that we expect that the most common implementation of EFI reset will be a thin wrapper around PSCI reset but we believe it is possible that some EFI reset methods may choose to reset a greater number of board-level devices before triggering a reset.
Some feedback on EBBR suggested that this doesn't match how an existing OS already behaves:
"Note: On platforms implementing the Power State Coordination Interface specification [PSCI], it is still required that EBBR compliant Operating Systems calls to reset the system will go via Runtime Services and not directly to PSCI."
It can be argued that the PSCI interfaces are more trustworthy than UEFI interface which requires running firmware code in the kernel context. Need to reevaluate this guidance before a v1.0 release