Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Restart dispatcher once MmEntryPoint is registered

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

On 11/22/23 16:11, Ard Biesheuvel wrote:
> On Wed, 22 Nov 2023 at 12:45, Laszlo Ersek <lersek@redhat.com> wrote:
>>
> ...
>> (3) Most importantly, speaking to a larger context, I don't understand
>> how this patch can work *at all*.
>>
>> Namely, I can find no MM IPL inside edk2!
>>
>> The DXE and MM dispatcher are supposed to work together in the following
>> way:
>>
>> (3.1) Whenever the DXE Core signals the PI-defined event group
>> EFI_EVENT_GROUP_DXE_DISPATCH_GUID, the MM IPL takes notice. (The MM IPL
>> learns that the DXE Dispatcher has completed one round of dispatching,
>> and new DXE/UEFI protocols may have become available.)
>>
>> (3.2) The MM IPL notifies the MM Core to run one round of MM dispatch.
>> This gives another chance to those MM drivers that failed to launch
>> previously due to missing DXE/UEFI protocols (which they might want to
>> consume in their entry points). The notification happens via an MMI / a
>> particular communication buffer carrying
>> EFI_EVENT_GROUP_DXE_DISPATCH_GUID in the header.
>>
>> (3.3) The MM Core runs said one round of dispatch, and then *informs*
>> the MM IPL about the result. The result can be one of three cases:
>> success, error, and "restart".
>>
>> (3.4) As long as the result is "restart" (for *whatever* reason), the MM
>> IPL doesn't complete the notification function for
>> EFI_EVENT_GROUP_DXE_DISPATCH_GUID, but jumps back to step (3.2).
>>
>> In practice, this is used for handling the situation described in the
>> commit message -- namely, if the MM Core notices that the MM Entry Point
>> was installed in the last round of MM dispatch, then it exits early back
>> to the MM IPL with status "restart". The subsequent MM Dispatch run
>> gives a chance to those MM drivers that needed access to Management Mode
>> (or perhaps MM RAM). So in effect this is an "inner" re-iteration that
>> aims at noticing the MM Entry Point, instead of new DXE/UEFI protocols.
>>
> 
> The above describes traditional MM but not standalone MM. I would have
> to refer to the PI spec for details, but the primary difference is
> that SMM drivers have no access to the DXE protocol database or boot
> services at all (hence the name 'standalone'). The standalone MM is a
> separate execution context that comes into existence magically (i.e.,
> in a way not defined by PI/UEFI) and can be invoked only via special
> traps or instructions. Notably, the SMM model where the initial
> context is unified and only separated later in the boot (at EndOfDxe?)
> does not apply here. This also means that dispatching FVs into
> standalone MM and retaining other SMM legacy is meaningless, which is
> why I removed all that code.

Right, this is what I suspected. It didn't seem like your code removal
was an incidental simplification; my understanding (or more like:
guesswork) of "Standalone" in "StandaloneMmPkg" was that there was *no*
MM "IPL" to talk back to.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111696): https://edk2.groups.io/g/devel/message/111696
Mute This Topic: https://groups.io/mt/102703852/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-