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

["Laszlo Ersek" <lersek@redhat.com>]

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