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

["Siyuan, Fu" <siyuan.fu@intel.com>]

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@intel.com>; rfc@edk2.groups.io;
> devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@intel.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>;
> ard.biesheuvel@arm.com; sami.mujawar@arm.com;
> supreeth.venkatesh@arm.com
> 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@intel.com>;
> >> rfc@edk2.groups.io
> >> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>;
> >> ard.biesheuvel@arm.com; sami.mujawar@arm.com; Yao, Jiewen
> >> <jiewen.yao@intel.com>; supreeth.venkatesh@arm.com
> >> 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
> >>
> >>
> >>
> >>
> >>
> >
> 
> 
> 
> 
>