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

Abner Chang

Heinrich Schuchardt <xypron.glpk@...> 於 2021年5月17日 週一 下午2:45寫道:
On 5/17/21 5:41 AM, Anup Patel wrote:
>> -----Original Message-----
>> From: Heinrich Schuchardt <xypron.glpk@...>
>> Sent: 17 May 2021 01:27
>> To: tech-unixplatformspec@...; Anup Patel
>> <Anup.Patel@...>; Sunil V L <sunilvl@...>;
>> renba.chang@...
>> Cc: tech-unixplatformspec@...
>> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] riscv-platform-spec:
>> Additional requirements to server extension
>> Am 16. Mai 2021 19:13:47 MESZ schrieb Anup Patel <anup.patel@...>:
>>> Hi,
>>> Please note that we should consider that Guest/VM will be directly
>>> running in VS-mode (S-mode without hypervisor capabilities) so UEFI
>>> firmware will be running entirely in S-mode inside Guest/VM for
>>> virtualization. In other words, Guest/VM will not have any M-mode
>>> resources such as PMP, ePMP, etc. Various distros will expect UEFI
>>> services to work fine inside Guest/VM.
>> At least U-Boot relies on OpemSBI for unaligned memory access and may use
>> it for sytem reset. Where will ecalls and exceptions be handled when running
>> in VS mode?
> The SBI calls for VS-mode will be provided by the HS-mode (KVM, Xvisor,
> Xen and other hypervisors).
> The OpenSBI provides SBI calls for HS-mode and provides other runtime
> features such as misaligned load/store emulation, TIME CSR emulations, etc.
> The boot-flow followed by U-Boot take care of virtualization as well.
> Particularly, the U-Boot S-mode is intended to run as-is unmodified in
> VS-mode.
> My point is that any UEFI implementation should consider this fact that
> inside Guest/VM there is no M-mode. This means any UEFI related
> requirements should only expect SBI calls and it should not matter who
> provides the SBI calls (OpenSBI or Hypervisors).
> Based on my understanding of EDK2 boot-flow, currently it is not as
> flexible as U-Boot + OpenSBI boot-flow. Since EDK2 is widely used
> as UEFI implementation, running directly in VS-mode should be
> supported by EDK2. Please correct me if I am wrong here.

Hi Anup,

OpenSBI and EDK2 are actually a peer, both of those are the boot firmware. On EDK2+OpenSBI solution, EDK2 uses OpenSBI as the library to leverage RISC-V platform code and SBI implementation. However, the system still boots based on the EDK2 architecture and execution phases.  Although OpenSBI is the library in EDK2, all of SBI calls are still go to OpenSBI. EDK2 and OpenSBI are in the one entity, just EDK2 provides firmware extension SBI to the later EFI drivers.

EDK2 is not necessary to be executed in VS mode, part of edk2 code stays in M-mode as same as OpenSBI. Another part runs in S-mode which dispatches S-Mode PEI drivers, S-Mode DXE drivers and M-Mode driver (management mode EFI driver). EDK2 can still start other HSM harts using firmware extension SBI for the vituralization at the end of post.

That would be difficult to have EDK2 runs on VS, there are many EDK2 drivers that communicate with the hardware operation region which is better isolated from other S-mode EFI drivers. Some of EFI driver are executed in management mode (could be M-mode in RISC-V) for the security and manageability. We don't want to see any S-Mode entities such as the S-mode EFI driver which is loaded from PCI option card can tamper or reverse engineering those code. Some memory regions are determined during POST and those memory region should be only accessed in M-mode to secure the content and prevent from S-mode EFI driver/software to modify it (e.g. management mode memory and PRM, the latter needs ePMP for the shared code/data).

Firmware extension SBI is only used for the EFI driver during POST, thus it is not a problem if EDK2 is executed in the M/S mode.  Also, as we discussed in another thread, we need OpenSBI allows switching to M-mode for the next phase only for the boot hart, boot firmware has to switch to S-mode before handing off to the next stage.

There are still some details of OpenSBI-EDK2 collaboration for the above need to discuss…


Currently EDK II provides OpenSBI as part of its SEC (Security) code in

When the hypervisor provides the SEC code we will need to enter directly
into the PEI (Pre-EFI Initialization Environment).


This will require a new platform variant but should not require changes
is main EDK II.

Right, if we have EDK2 in VS, we will need another platform for this.  But the platform that conforms with what I mentioned in above should be also supported, that is the main stream edk2 RISC-V variant to afford the current OEM implementations (PC/notebook and server).



Best regards


> Regards,
> Anup
>> Best regards
>> Heinrich
>>> Regards,
>>> Anup
>>> Get Outlook for Android<>
>>> ________________________________
>>> From: tech-unixplatformspec@...
>>> <tech-unixplatformspec@...> on behalf of Sunil V L
>>> <sunilvl@...>
>>> Sent: Sunday, May 16, 2021 7:17:56 PM
>>> To: renba.chang@... <renba.chang@...>
>>> Cc: tech-unixplatformspec@...
>>> <tech-unixplatformspec@...>
>>> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH]
>>> riscv-platform-spec: Additional requirements to server extension
>>> 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.
>>>> 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
>>>>   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
>>>> --

Join { to automatically receive all group messages.