1. Messages
  2. [PATCH] riscv-platform-spec: Additional requirements to server extension

Re: [PATCH] riscv-platform-spec: Additional requirements to server extension

Abner Chang
 



Sunil V L <sunilvl@...> 於 2021年5月16日 週日 下午9:48寫道：
Hi Abner,

On Tue, May 11, 2021 at 09:48:42AM +0800, renba.chang@... wrote:
> From: Abner Chang <renba.chang@...>
>
> Add more server extensions to align with current server firmware implementation and the future technology.
>
> @Sunil, I would like to add below placeholders to server extension in order to align with the server platform implementation.
>
> 1. RISC-V port of Management Mode EFI protocols, most of servers had implemented EFI MM driver to handle the critical errors, security, in-band BMC operations, remote management and etc features.
> Some of those features have dependencies with chipset or processor-arch, but some of those are chipset and processor-arch agnostic. Having RISC-V EFI MM protocols as the server extension to support the latter use case for cross platform FW MM driver implementation.
>
> 2. PRM (Platform Runtime Mechanism)
>    Addition to the use cases implemented based on #1, UEFI PRM is provided to enable OS capability to invoke OS agnostic FW procedures for ACPI or error handling directly without generating software management mode event. Leverage ePMP shared code/data regions for M-Mode/S-Mode entities to co-manage PRM data/code region.
>

My understanding is, these features are introduced to reduce some of the
issues with SMM mode in x86. I am not sure whether we will have similar
issues in risc-v and need to make this feature mandatory. I think each
of these need a separate discussion involving SBI experts. I understand
your intention here is to have a section to trigger further
investigation. If so, it looks fine to me unless someone else have an
objection.
Yes, one of the reasons for having PRM is to reduce the issue of SMI that brings processors to the highest privilege mode (higher than ring-0 on x86 for example). However, it also encourages firmware runtime procedures for ACPI or error handings to be executed by OS instead of triggering a management mode interrupt and handled by FW. That means firmware code could be moved out from management mode which is a black box to OS. I think most of the POC code for launching PRM driver was done by Intel in edk2-staging repo. For RISC-V, we can leverage ePMP haveing a M/S Mode shared code/data region for PRM (the concerns Anup mentioned could be an issue) . Have PRM doesn't mean the management mode EFI driver is no longer exists. OEM still has MM driver for the proprietary features, particular error handing, BCM/Host communication and etc. That is why #1 is still important for the server platforms.

Regards,
Abner
 

> 3. RTC (Real Time Clock)
>    Real time clock is the server basic system peripheral to provide the real date/time information for server to manage the system date, time and time zones settings for different regions through the local POST time firmware utility, NTP or the remote management such as Redfish.
>
Agree.

Regards
Sunil

> Signed-off-by: Abner Chang <renba.chang@...>
> Cc: Sunil V L <sunilvl@...>
> ---
>  riscv-platform-spec.adoc | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 160c74a..55c5735 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -245,8 +245,15 @@ implemented but it can return EFI_UNSUPPORTED.
>  implemented but it can return EFI_UNSUPPORTED.
>  |===
> 
> +====== Management Mode
> +====== UEFI Platform Runtime Mechanism
> +* PRM Module
> +* ACPI PRMT Table
> +* Enhanced PMP Shared Memory Region
> +
>  ==== System Peripherals
>  * PCI-E
> +* Real Time Clock
> 
>  ==== Secure Boot
>  * TEE
> --
> 2.19.0.windows.1
>

Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.