Re: [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core


Siyuan, Fu <siyuan.fu@...>
 

Hi, Sami

I know the traditional MM is planned to be deprecated but the reality is that there
are many existing traditional MM platforms/drivers and the migration has to happen
step-by-step. It may take a long time like several years, not days or months. Not sure
if we really want to maintain duplicate code in 3 different MM cores in EDK2 for
such a long time.

Would you think it's acceptable if we put the traditional MM related code controlled
by a feature flag PCD in StandaloneMmPkg core? The default value of the PCD can
be set as disabled so those existing platforms doesn't need to be changed.

Best Regards
Siyuan

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sami
Mujawar
Sent: 2020年10月15日 18:12
To: Fu, Siyuan <siyuan.fu@...>; devel@edk2.groups.io;
lersek@...; Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io;
Laszlo Ersek (lersek@...) <lersek@...>
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Ard
Biesheuvel <Ard.Biesheuvel@...>; Supreeth Venkatesh
<Supreeth.Venkatesh@...>
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

Hi Siyuan,

I can see the following points:
- current code organisation is such that the traditional MM and standalone MM
are clearly separated.
- traditional MM is planned to be deprecated.
- some architectures only support standalone MM (e.g. Arm platforms)
- life span of MM Migration use-case code is until traional MM is deprecated.

Considering the above, would it be possible to have an option 3 where the MM
Migration use-case code is placed in a separate location/package, such that
existing platforms do not need changing and are not regressed?
I understand the concern with duplicating the MM implementations, however I
think it would be good to maintain the demarcation that exists between
traditional MM and standalone MM. Features that are beneficial to standalone
MM can certainly be added to StandaloneMmPkg.

Regards,

Sami Mujawar

-----Original Message-----
From: Fu, Siyuan <siyuan.fu@...>
Sent: 10 October 2020 02:41 AM
To: devel@edk2.groups.io; lersek@...; Yao, Jiewen
<jiewen.yao@...>; rfc@edk2.groups.io; Laszlo Ersek (lersek@...)
<lersek@...>
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Ard
Biesheuvel <Ard.Biesheuvel@...>; Sami Mujawar
<Sami.Mujawar@...>; Supreeth Venkatesh
<Supreeth.Venkatesh@...>
Subject: RE: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

Hi, Jiewen/Laszlo

Thanks for your comments on this.

Hi, Ard/Sami/Supreeth

Since ARM based platforms are currently the major user of the MM Core in
StandaloneMmPkg, I would like to hear you idea about this change. Do you have
any concern about adding MM Traditional driver support to the Standalone MM
Core?

Best Regards
Siyuan

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: 2020年10月9日 21:08
To: Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io;
devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...>
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>;
ard.biesheuvel@...; sami.mujawar@...;
supreeth.venkatesh@...
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

On 10/09/20 14:23, Yao, Jiewen wrote:
IMHO, StandaloneMm (in StandaloneMmPkg) should be the long term
direction to replace the traditional MM (in MdeModulePkg).

If we want to do some enhancement, I prefer #2 to update the one in
StandaloneMmPkg.
Once we retire transitional MM, we can delete the PiSmmCore in
MdeModulePkg.

This is a good idea -- when we think we are ready to retire PiSmmCore in
MdeModulePkg, because we think that StandaloneMmPkg can fully replace
it, platforms can evaluate the latter (hopefully with some simple DSC /
FDF modifications), and report back whether they see regressions or
whether StandaloneMmPkg behaves as a drop-in replacement indeed, for
PiSmmCore in MdeModulePkg.

Thanks
Laszlo


If we choose #1, the EDKII will have two standaloneMm Cores (the one in
StandaloneMmPkg and the one in MdeModulePkg), which may bring lots of
confusing and we may need merge them later.

Thank you
Yao Jiewen

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Friday, October 9, 2020 7:56 PM
To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...>;
rfc@edk2.groups.io
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>;
ard.biesheuvel@...; sami.mujawar@...; Yao, Jiewen
<jiewen.yao@...>; supreeth.venkatesh@...
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

On 10/09/20 07:22, Siyuan, Fu wrote:
Hi, All

This email is to collect feedback about making one common EDK2 MM
Core
driver to support both MM Traditional drivers and MM Standalone drivers.

We know that PI Spec defines two types of MM-related drivers: MM
Traditional Drivers and MM Standalone Drivers. There are two MM Core
modules exist in EDK2 but each of them can only support one single type of
MM
drivers:
- PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch.
It
doesn't have FV parsing logic and relies on EFI Firmware Volume2 Protocol
for
driver discovery. It doesn't support MM Standalone driver.
- StandaloneMmCore in StandaloneMmPkg supports MM Standalone
driver
dispatch. It has FV parsing and decompress logic but only limited to one
single
firmware volume (called standalone BFV in code). It doesn't support MM
Traditional driver.

However, a platform may want to have both of the two types of MM
drivers
coexist in its firmware, for example, when it tries to transfer from
Traditional
MM mode to Standalone MM mode, in a stage by stage manner. However,
it's
not possible with current EDK2 MM Core because of above limitations. Thus,
here we propose to have a common MM Core module in EDK2, which could:
- Support both MM Traditional drivers and MM Standalone drivers.
- Use shared Depex evaluation when dispatching all the MM drivers.
- Use a shared MM System Table when invoking all the MM drivers'
entry
point, which mean handle/protocol database is shared.
- Have self-contained FV parsing and driver discovery capability.

We realized there could be 2 possible options to make this happen:
- Option 1: Update the MdeModulePkg Core. In this approach, we will
need
to add the FV decompress, driver discovery and MM Standalone driver
dispatcher to the PiSmmCore module in MdeModulePkg.
- Option 2: Update the StandaloneMmPkg Core. Which means adding
MM
Traditional dispatcher and multiple FV support to existing standalone Core
in
StandaloneMmPkg. Will also need to add PEI/DXE IPL module to invoke the
Standalone MM Core and pass UEFI System Table to it.

The option 1 will have less impact to those platforms which only use MM
Standalone drivers currently, because those platforms can stay with the
unchanged Standalone MM Core. While option 2 looks more like a clean
solution because it could support all the cases (Traditional MM only,
Standalone
MM only, and mix-used platform). So I'd like to hear the community's
feedback
about which option is preferred, and let me know if you have any concerns
with
this change. Thanks!

Which method is the least risky with regard to regressions, in your opinion?

I tend to prefer #2. Either option is neutral for ArmVirtPkg at the
moment, and option#2 is safer for OvmfPkg (no risk of regression). Thus
far, there has not been any need (that I know of) for OVMF to support
standalone MM drivers.

Furthermore, if we wanted to add Management Mode support to
ArmVirtPkg
at some (later) point, I believe (?) we'd just use StandaloneMmPkg right
from the start.

I.e., from my perspective, mixing MM module types, for some kind of
transition for a platform from one MM mode to another, is not
immediately useful; so my goal is to minimize the risk of regressions.

Thanks
Laszlo







IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.



Join rfc@edk2.groups.io to automatically receive all group messages.