BootScriptExecutorDxe, to be pulled in in the next patch, was written with
the SMM implementation of LockBox in mind. That implementation is split in
the following three parts:
- client side (DXE/PEI) library,
- SMM driver producing gEfiLockBoxProtocolGuid,
- driver side (SMM) library.
BootScriptExecutorDxe includes the client side LockBoxLib. So that the
library can communicate with the SMM LockBox driver, BootScriptExecutorDxe
has a Depex on gEfiLockBoxProtocolGuid, normally installed by the SMM
LockBox driver. This is actually not a hard dependency, it just ensures
correct load order between BootScriptExecutorDxe and
MdeModulePkg/Universal/LockBox/SmmLockBox.
The (client side) LockBox library instance in OVMF doesn't depend on a
separate driver that produces gEfiLockBoxProtocolGuid. Nothing produces
that GUID right now in OVMF. This prevents BootScriptExecutorDxe from
loading.
Install gEfiLockBoxProtocolGuid in our only S3-specific, custom DXE
driver, in order to enable loading of BootScriptExecutorDxe.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15306 6f19259b-4bc3-4df7-8a09-765794883524
The trigger to actually save the boot script is the installation of
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL, to be performed by any DXE driver.
Installation of the protocol also locks down SMM (as its name indicates)
and (in theory) prevents further LockBox access.
We cannot install this protocol before BdsLibBootViaBootOption() is called
(eg. in OVMF's PlatformBdsPolicyBehavior()), because
BdsLibBootViaBootOption() calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save(), which
needs LockBox access.
We also can't install the protocol after BdsLibBootViaBootOption()
returns, simply because control is never returned to us.
Therefore modify our EFI_ACPI_S3_SAVE_PROTOCOL implementation so that the
boot script is prepared and installed internally to S3Save().
(The boot script must contain at least one opcode, otherwise
S3BootScriptLib runs into an assertion failure. We add a harmless (no-op)
"information" opcode.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15305 6f19259b-4bc3-4df7-8a09-765794883524
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf"
currently specifies a DepEx on gEfiMpServiceProtocolGuid (MP Services).
The justification is the following code sequence:
InstallAcpiS3Save()
if PcdFrameworkCompatibilitySupport is set:
InstallAcpiS3SaveThunk()
if EFI_MP_SERVICES_PROTOCOL is available:
GetVariable(ACPI_GLOBAL_VARIABLE)
In English, the AcpiS3SaveDxe driver insists on the presence of MP
Services *unconditionally* because,
- if PcdFrameworkCompatibilitySupport is set (the default is false),
- and MP Services are available (which is constant true under the above
condition),
then the AcpiS3SaveDxe driver would like to get the ACPI_GLOBAL_VARIABLE
variable from the MP Services driver, rather than setting it itself.
The DepEx prevents AcpiS3SaveDxe from loading under OvmfPkg, since we
provide no MP Services implementation. This is particularly broken since
the default PcdFrameworkCompatibilitySupport value is FALSE, making the
entire code that would look at EFI_MP_SERVICES_PROTOCOL dead.
Copy AcpiS3SaveDxe to OvmfPkg, substitute PcdFrameworkCompatibilitySupport
with constant FALSE, and remove all code that becomes dead, including the
DepEx.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15302 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek