In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox
protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol
in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe
customizations remain valid (or harmless), said change is invalid when
OVMF is built with -D SMM_REQUIRE and includes the real protocol provider,
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19045 6f19259b-4bc3-4df7-8a09-765794883524
At this point, nothing in the OVMF build calls EFI_ACPI_S3_SAVE_PROTOCOL
member functions; simplify the code by dropping this protocol interface.
Cc: Jordan Justen <jordan.l.justen@intel.com>
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@18038 6f19259b-4bc3-4df7-8a09-765794883524
Currently we have the following call chain in OVMF:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
SaveS3BootScript() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The bottom of this call chain was introduced in git commit 5a217a06 (SVN
r15305, "OvmfPkg: S3 Suspend: save boot script after ACPI context"). That
patch was necessary because there was no other way, due to GenericBdsLib
calling S3Save() from BdsLibBootViaBootOption(), to perform the necessary
steps in the right order:
- save S3 system information,
- save a final (well, only) boot script opcode,
- signal DxeSmmReadyToLock, closing the boot script, and locking down
LockBox and SMM.
The GenericBdsLib bug has been fixed in the previous patch -- the call in
BdsLibBootViaBootOption() has been eliminated.
Therefore, hoist the SaveS3BootScript() code, and call, from
OvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
<---
SaveS3BootScript() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The installation of DxeSmmReadyToLockProtocol belongs with Platform BDS,
not AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without
upsetting the relative order of the steps.
Cc: Jordan Justen <jordan.l.justen@intel.com>
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@18037 6f19259b-4bc3-4df7-8a09-765794883524
Call S3Ready() whenever the first of the following occurs:
- a driver signals End-of-Dxe,
- a driver calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save().
S3Ready() already contains a static, function scope "latch" that causes it
to exit early when called for the second time or later.
(At the moment, the only platform in the edk2 tree that includes this
driver is OvmfPkg. That platform does not signal End-of-Dxe (yet).)
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146
Suggested-by: Yao Jiewen <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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@18034 6f19259b-4bc3-4df7-8a09-765794883524
We are preparing for detaching the S3Ready() functionality from the
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we
will hook the same logic to the End-of-Dxe event group.
The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().
According to the documenation,
This function returns the size of the legacy memory (meaning below 1 MB)
that is required during an S3 resume. Before the Framework-based
firmware transfers control to the OS, it has to transition from flat
mode into real mode in case the OS supplies only a real-mode waking
vector. This transition requires a certain amount of legacy memory.
After getting the size of legacy memory below, the caller is responsible
for allocating the legacy memory below 1 MB according to the size that
is returned. The specific implementation of allocating the legacy memory
is out of the scope of this specification.
When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the
legacy memory allocated above must be passed to it, in the
LegacyMemoryAddress parameter.
In practice however:
- The S3Ready() function ignores the LegacyMemoryAddress completely.
- No code in the edk2 tree calls
EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.
- All callers of this specific implementation of
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL
LegacyMemoryAddress:
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never
called, and that the LegacyMemoryAddress parameter is always NULL.
This fact is important to capture in the code, because in the End-of-Dxe
callback, no LegacyMemoryAddress parameter can be taken. So let's make it
clear that we actually don't even have any use for that parameter.
This patch ports the identical change from IntelFrameworkModulePkg to
OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
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@18033 6f19259b-4bc3-4df7-8a09-765794883524
We are preparing for detaching the S3Ready() functionality from the
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we
will hook the same logic to the End-of-Dxe event group.
The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().
According to the documenation,
This function returns the size of the legacy memory (meaning below 1 MB)
that is required during an S3 resume. Before the Framework-based
firmware transfers control to the OS, it has to transition from flat
mode into real mode in case the OS supplies only a real-mode waking
vector. This transition requires a certain amount of legacy memory.
After getting the size of legacy memory below, the caller is responsible
for allocating the legacy memory below 1 MB according to the size that
is returned. The specific implementation of allocating the legacy memory
is out of the scope of this specification.
When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the
legacy memory allocated above must be passed to it, in the
LegacyMemoryAddress parameter.
In practice however:
- The S3Ready() function ignores the LegacyMemoryAddress completely.
- No code in the edk2 tree calls
EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.
- All callers of this specific implementation of
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL
LegacyMemoryAddress:
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never
called, and that the LegacyMemoryAddress parameter is always NULL.
This fact is important to capture in the code, because in the End-of-Dxe
callback, no LegacyMemoryAddress parameter can be taken. So let's make it
clear that we actually don't even have any use for that parameter.
This patch ports the identical change from IntelFrameworkModulePkg to
OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17806 6f19259b-4bc3-4df7-8a09-765794883524
The previous patch ensures that the LockBox is protected during DXE (but
the OS can still drop it) if S3 is unsupported or disabled. However, S3
related drivers not only save data in the lockbox, they allocate objects
with Reserved and AcpiNVS memory types too, which the OS can't (must not)
release. This is a waste when S3 is unsupported or disabled.
In OVMF a good "choke point" for these drivers is the entry point of
AcpiS3SaveDxe. The messages of the following commits are relevant to the
data and control flow:
- SVN r15290 (git commit 8f5ca05b)
- SVN r15305 (git commit 5a217a06)
- SVN r15306 (git commit d4ba06df)
Prevent AcpiS3SaveDxe from loading when S3 is unsupported or disabled.
This should keep away (most of the) dependent drivers too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15419 6f19259b-4bc3-4df7-8a09-765794883524
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
Jordan Justen