summaryrefslogtreecommitdiff
path: root/OvmfPkg/AcpiTables
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2014-03-04 08:04:04 +0000
committerjljusten <jljusten@6f19259b-4bc3-4df7-8a09-765794883524>2014-03-04 08:04:04 +0000
commitd4ba06dfdc3a0c2f6519d3dcaf4437e164d4ac91 (patch)
tree83a6b01a2919df5493d45307daaeccea64d78175 /OvmfPkg/AcpiTables
parent5a217a0649b31db2f0e7a65e42f92fbebc3bef96 (diff)
downloadedk2-d4ba06dfdc3a0c2f6519d3dcaf4437e164d4ac91.zip
edk2-d4ba06dfdc3a0c2f6519d3dcaf4437e164d4ac91.tar.gz
edk2-d4ba06dfdc3a0c2f6519d3dcaf4437e164d4ac91.tar.bz2
OvmfPkg: S3 Resume: fake LockBox protocol for BootScriptExecutorDxe
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
Diffstat (limited to 'OvmfPkg/AcpiTables')
0 files changed, 0 insertions, 0 deletions