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

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

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@intel.com>; devel@edk2.groups.io;
> lersek@redhat.com; Yao, Jiewen <jiewen.yao@intel.com>; rfc@edk2.groups.io;
> Laszlo Ersek (lersek@redhat.com) <lersek@redhat.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Ard
> Biesheuvel <Ard.Biesheuvel@arm.com>; Supreeth Venkatesh
> <Supreeth.Venkatesh@arm.com>
> 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@intel.com>
> Sent: 10 October 2020 02:41 AM
> To: devel@edk2.groups.io; lersek@redhat.com; Yao, Jiewen
> <jiewen.yao@intel.com>; rfc@edk2.groups.io; Laszlo Ersek (lersek@redhat.com)
> <lersek@redhat.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Ard
> Biesheuvel <Ard.Biesheuvel@arm.com>; Sami Mujawar
> <Sami.Mujawar@arm.com>; Supreeth Venkatesh
> <Supreeth.Venkatesh@arm.com>
> 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@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
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> >
> >
> >
> >
> >
> 
> 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.
> 
> 
> 
>