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

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

-----Original Message-----
From: <> On Behalf Of Ard
Sent: 2020年10月16日 15:04
To: Fu, Siyuan <siyuan.fu@...>;;
sami.mujawar@...; lersek@...; Yao, Jiewen
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <>; Supreeth
Venkatesh <Supreeth.Venkatesh@...>
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

On 10/16/20 3:36 AM, Fu, Siyuan wrote:
Hi, Sami

I know the traditional MM is planned to be deprecated but the reality is that
are many existing traditional MM platforms/drivers and the migration has to
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
such a long time.
Could you explain more about the gap that needs to be bridged here? I
suppose the desire is to be able to reuse existing DXE_SMM_DRIVER
modules, and deploy them unmodified in a standalone MM context?
Yes you are correct. Without a hybrid MM core, the MM drivers must be
either all traditional MM or all standalone MM. While a platform may have
tens or even hundreds of traditional MM drivers for now, it's hard to covert
all of them into standalone as a single step. It looks ideal from architecture
perspective but actually very hard for a read product execution. So it will be
good if there is a hybrid MM core which can support both the unmodified
traditional MM driver, and converted standalone MM driver.

So would you expect runtime dispatch for these drivers? What about any
accesses to EFI boot services, which are no longer possible when running
under standalone MM? Do you have any reason to believe that this hybrid
MM core will be able to run a significant fraction of those existing
Runtime dispatch for standalone MM driver can be supported, but runtime
dispatch for traditional MM driver is not required (actually prohibited).
The hybrid MM core can distinguish the type of an MM module and decide
if it can be dispatched at a given execution point.

Would you think it's acceptable if we put the traditional MM related code
by a feature flag PCD in StandaloneMmPkg core? The default value of the PCD
be set as disabled so those existing platforms doesn't need to be changed.
This is security critical code, and having PCD controlled behavior like
this makes it much hard to reason about correctness in all its
instantiation. I guess I would have to see what the code looks like, but
having PCD checks all over the place does not seem like a great way to
do this IMHO.
I understand your concern. So I assume we all understand the value for
having a hybrid MM core, but the question is whether adding to existing
StandaloneMmPkg Core or a 3rd MM core in EDK2, right? I think we can
leave this as an open and make decision when reviewing the patch.



Join to automatically receive all group messages.