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

["Ard Biesheuvel" <ardb@kernel.org>]

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.


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