On 11/22/23 16:11, Ard Biesheuvel wrote: > On Wed, 22 Nov 2023 at 12:45, Laszlo Ersek <ler...@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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-