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


Abner Chang
 

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.

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.

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


Greg Favor
 

On Mon, May 10, 2021 at 6:48 PM Abner Chang <renba.chang@...> wrote:
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.

I notice that ARM SBSA does not specify an RTC nor does it even make any mention of requiring some form of RTC. That suggests that an RTC mandate is maybe not necessary in RISC-V's rough equivalent of SBSA?

In other words, why does RISC-V's server platform spec need to mandate an RTC, yet ARM's SBSA spec doesn't need to?

Greg


Abner Chang
 



Greg Favor <gfavor@...> 於 2021年5月11日 週二 上午9:55寫道:
On Mon, May 10, 2021 at 6:48 PM Abner Chang <renba.chang@...> wrote:
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.

I notice that ARM SBSA does not specify an RTC nor does it even make any mention of requiring some form of RTC. That suggests that an RTC mandate is maybe not necessary in RISC-V's rough equivalent of SBSA?

In other words, why does RISC-V's server platform spec need to mandate an RTC, yet ARM's SBSA spec doesn't need to?

It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.
Abner

Greg


Rahul Pathak
 



On Tue, May 11, 2021 at 8:55 AM Abner Chang <renba.chang@...> wrote:


Greg Favor <gfavor@...> 於 2021年5月11日 週二 上午9:55寫道:
On Mon, May 10, 2021 at 6:48 PM Abner Chang <renba.chang@...> wrote:
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.

I notice that ARM SBSA does not specify an RTC nor does it even make any mention of requiring some form of RTC. That suggests that an RTC mandate is maybe not necessary in RISC-V's rough equivalent of SBSA?

In other words, why does RISC-V's server platform spec need to mandate an RTC, yet ARM's SBSA spec doesn't need to?

It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.
Abner
Are you mandating RTC in hardware or just UEFI RTC Interfaces in case RTC is present? We need to make this clear.

Greg


Abner Chang
 



Rahul Pathak <rpathak@...> 於 2021年5月11日 週二 上午11:53寫道:


On Tue, May 11, 2021 at 8:55 AM Abner Chang <renba.chang@...> wrote:


Greg Favor <gfavor@...> 於 2021年5月11日 週二 上午9:55寫道:
On Mon, May 10, 2021 at 6:48 PM Abner Chang <renba.chang@...> wrote:
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.

I notice that ARM SBSA does not specify an RTC nor does it even make any mention of requiring some form of RTC. That suggests that an RTC mandate is maybe not necessary in RISC-V's rough equivalent of SBSA?

In other words, why does RISC-V's server platform spec need to mandate an RTC, yet ARM's SBSA spec doesn't need to?

It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.
Abner
Are you mandating RTC in hardware or just UEFI RTC Interfaces in case RTC is present? We need to make this clear.
It is in hardware generically (Not sure if there is an alternative solution that is not a hardware-based real-time clock but still can provide the date/time.)  EFI GetTime which just an abstract API to get the information from any form of RTC.
Abner

Greg


Greg Favor
 

On Mon, May 10, 2021 at 8:53 PM Rahul Pathak <rpathak@...> wrote:
It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.
Abner

Where are you seeing this?  The latest SBSA 7.0 and BSA 1.0 make no mention of this (or any RTC-related requirement).

Greg


Rahul Pathak
 



On Tue, May 11, 2021 at 10:39 AM Greg Favor <gfavor@...> wrote:
On Mon, May 10, 2021 at 8:53 PM Rahul Pathak <rpathak@...> wrote:
It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.
Abner

Where are you seeing this?  The latest SBSA 7.0 and BSA 1.0 make no mention of this (or any RTC-related requirement).
These are UEFI requirements which are part of SBBR 

Greg


Sunil V L
 

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 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


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.

Regards,
Anup

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 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
>






Heinrich Schuchardt
 

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?

Best regards

Heinrich


Regards,
Anup

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
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 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







Anup Patel
 

-----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.

Regards,
Anup


Best regards

Heinrich


Regards,
Anup

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
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
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







Heinrich Schuchardt
 

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.
Currently EDK II provides OpenSBI as part of its SEC (Security) code in
edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi.

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

Cf.
https://gblobscdn.gitbook.com/assets%2F-M5spcVt2sqlUZOWmnXY%2F-M5sphJDWD7_iUuoREya%2F-M5spjTOFjRbcY8ckkSh%2Fimage3.png?alt=media

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

Best regards

Heinrich


Regards,
Anup


Best regards

Heinrich


Regards,
Anup

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
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
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










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
>


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
edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi.

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

Cf.
https://gblobscdn.gitbook.com/assets%2F-M5spcVt2sqlUZOWmnXY%2F-M5sphJDWD7_iUuoREya%2F-M5spjTOFjRbcY8ckkSh%2Fimage3.png?alt=media

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).


Regards,

Abner



Best regards

Heinrich

>
> Regards,
> Anup
>
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Regards,
>>> Anup
>>>
>>> Get Outlook for Android<https://aka.ms/AAb9ysg>
>>> ________________________________
>>> 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
>> 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
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>