On 05/07/20 18:45, Bret Barkelew wrote: > I know I've also seen tests that randomize the driver dispatch order > to try to catch these "implementation-specific" edge cases. Perhaps we > could instrument something similar with a weekly OVMF CI test?
That won't work for -- at least -- the SMM_REQUIRE build of OVMF. Consider the following FDF snippet: > !if $(SMM_REQUIRE) == TRUE > [...] > INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf > > # > # Variable driver stack (SMM) > # > INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf > INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf > INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf > INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf > > !else The pflash detection in FvbServicesSmm can only function if FvbServicesSmm is dispatched after PiSmmCpuDxeSmm. QEMU restricts pflash write accesses to such guest code that runs in SMM. And if FvbServicesSmm is dispatched before PiSmmCpuDxeSmm, then FvbServicesSmm does not run in SMM, and the pflash detection fails. ( Note: the question is not whether FvbServicesSmm runs *from SMRAM* (that's a given), but whether it runs *in SMM*. Regardless of the dispatch order, SMRAM is open (not closed) at this point, so FvbServicesSmm *can* run from SMRAM without the VCPU being in SMM. But in that case, QEMU denies pflash writes, and so the pflash detection fails. ) In 2016, there was an attempt to add a new dependency to PiSmmCpuDxeSmm, which ended up reversing the desired dispatch order between PiSmmCpuDxeSmm and FvbServicesSmm. That triggered the above problem, and we discussed it back then. At the time, I did try enforcing the right dispatch order with adding a DEPEX to FvbServicesSmm. But then the rest of the variable stack (which builds upon the SMM FVB protocol produced by FvbServicesSmm) fell apart. See my 2016 writeup here: http://mid.mail-archive.com/cc211d5f-18f3-57c8-7b4f-d4f3433898f7@redhat.com ( Alternative link: https://lists.01.org/hyperkitty/list/edk2-de...@lists.01.org/message/WE3NGL24WTEB6E56MOJMVFBOIKPLKC3Q/ ) The PiSmmCpuDxeSmm DEPEX that upset the dispatch order for OVMF got ultimately reverted in commit eadf70bdfbc1 ("UefiCpuPkg/PiSmmCpuDxeSmm: Revert 7503cd70fb86", 2016-08-19). (My understanding is that the same DEPEX ended up being injected into PiSmmCpuDxeSmm in a particular platform tree (not in edk2), via that platform's SmmCpuFeaturesLib instance -- PiSmmCpuDxeSmm consumes SmmCpuFeaturesLib.) Part of the complication is *likely* that VariableSmm only has TRUE for Depex: - VariableSmm consumes the SMM FTW protocol produced by FaultTolerantWriteSmm, but that protocol is not in the DEPEX, it's awaited with an SMM protocol notify. - VariableSmm also consumes the SMM FVB protocol produced by FvbServicesSmm, but that protocol is not waited-for in *any* way (neither DEPEX nor notify). Only attempts are made to locate it. I *guess* (but haven't tracked down) that the SMM FVB availability is inferred from the SMM FTW availability (FaultTolerantWriteSmm does have an explicit DEPEX on SMM FVB). The (working) dispatch order seen in the OVMF log file is: > Loading SMM driver at 0x0007D094000 EntryPoint=0x0007D09D0B3 > PiSmmCpuDxeSmm.efi > Loading SMM driver at 0x0007D042000 EntryPoint=0x0007D047677 > FvbServicesSmm.efi > Loading SMM driver at 0x0007CF68000 EntryPoint=0x0007CFF882E VariableSmm.efi > Loading SMM driver at 0x0007CE05000 EntryPoint=0x0007CE0923C > SmmFaultTolerantWriteDxe.efi > Loading driver at 0x0007BAA0000 EntryPoint=0x0007BAA47E2 > VariableSmmRuntimeDxe.efi Note a few things: - FaultTolerantWriteSmm calls itself "SmmFaultTolerantWriteDxe" via its BASE_NAME (functionally harmless, but confusing). - The dispatch order between PiSmmCpuDxeSmm and FvbServicesSmm is as desired. - VariableSmm and FaultTolerantWriteSmm are *already* dispatched in reverse order relative to the FDF file. This -- while not wrong -- does not seem necessary for satisfying any DEPEX, as far as I can see. This is one of those "dark corners". Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58873): https://edk2.groups.io/g/devel/message/58873 Mute This Topic: https://groups.io/mt/74054729/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
