IMHO, StandaloneMm (in StandaloneMmPkg) should be the long term direction to replace the traditional MM (in MdeModulePkg).
toggle quoted message
Show quoted text
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.
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.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Laszlo Ersek
Sent: Friday, October 9, 2020 7:56 PM
To: email@example.com; Fu, Siyuan <siyuan.fu@...>;
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>;
ard.biesheuvel@...; sami.mujawar@...; Yao, Jiewen
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, Alldriver to support both MM Traditional drivers and MM Standalone drivers.
This email is to collect feedback about making one common EDK2 MM Core
Traditional Drivers and MM Standalone Drivers. There are two MM Core
We know that PI Spec defines two types of MM-related drivers: MM
modules exist in EDK2 but each of them can only support one single type of MM
- PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch. Itdoesn'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 driverdispatch. 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
coexist in its firmware, for example, when it tries to transfer from Traditional
However, a platform may want to have both of the two types of MM drivers
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.point, which mean handle/protocol database is shared.
- Use shared Depex evaluation when dispatching all the MM drivers.
- Use a shared MM System Table when invoking all the MM drivers' entry
- Have self-contained FV parsing and driver discovery capability.to add the FV decompress, driver discovery and MM Standalone driver
We realized there could be 2 possible options to make this happen:
- Option 1: Update the MdeModulePkg Core. In this approach, we will need
dispatcher to the PiSmmCore module in MdeModulePkg.
- Option 2: Update the StandaloneMmPkg Core. Which means adding MMTraditional 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.
Standalone drivers currently, because those platforms can stay with the
The option 1 will have less impact to those platforms which only use MM
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.