Zeng, Star wrote:
]Hi Sava,
]
]Yes, it is a real problem. I agree "a more careful handling of this
]case is a good idea".
]We will fix this case.
]Thanks very much.
]Star
This problem was first reported on 11/24/2013, along with a
slightly simpler fix than that proposed by A. Sava:
Hi Sava,
Yes, it is a real problem. I agree "a more careful handling of this case is a
good idea".
We will fix this case.
Thanks very much.
Star
From: A. Sava [mailto:asava@gmail.com]
Sent: Wednesday, December 25, 2013 5:25 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] DXE phase h
There is a problem starting in edk2 r14587 - DXE phase may halt at
initialising PCD when PEI is empty.
The problem is at MdeModulePkg/Universal/PCD/Dxe/Service.c @
BuildPcdDxeDataBase ():
GuidHob = GetFirstGuidHob (&gPcdDataBaseHobGuid);
if (GuidHob != NULL) {
//
// If no PEIMs use d
AcpiS3SaveDxe has a runtime dependency (enforced via ASSERT ()) on
SmmLockBox (which in turn depends on the SMRAM we emulate as part of the
NVRAM). Make the dependency explicit in the Depex section of the driver,
similarly to what BootScriptExecutorDxe does. When the SMRAM is not
available, not loa
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf" produces
gEfiSmmLockBoxCommunicationGuid, implementing LockBox services in SMRAM
for the SmmLockBoxLib library (used in the following patches).
gEfiSmmLockBoxCommunicationGuid
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
gEfiSmmSwDispatc
Although SVN r14944 ("OvmfPkg: introduce PublishPeiMemory") copied a big
chunk of code from MemDetect(), calling the new PublishPeiMemory()
function in MemDetect() could not have replaced the original code in the
latter. However, with the help of the previous patch, we can do it now.
Contributed-u
"MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces
the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3
Boot Script, to be replayed in PEI during S3 Resume. The script contains
opcodes and opcode arguments to configure CPU, PCI and IO resources.
S3SaveStat
In addition to the NVRAM emulation made dependent on S3 support in the
previous patch, if the host admin turns off S3 for the guest, there is
also no need to reserve the following ranges from the OS, as AcpiNVS type
memory (see "OvmfPkg/PlatformPei/MemoryMap.txt"):
- [0x007, 0x007]: early
The current implementation of QemuFwCfgLib is:
- stateful
- implicitly initialized in the library constructor.
OVMF's SEC runs from read-only memory/flash. When the library is linked
into a SEC binary (which currently never happens), the
"mQemuFwCfgSupported" global variable becomes read-only, mak
The QemuFwCfgSecLib library instance
- is stateless,
- has no library constructor,
- is available to SEC client code,
- must be queried with QemuFwCfgIsAvailable() before use,
- is restricted to SEC in order to limit the explicit querying
requirement. (There is no current user.)
Contributed-unde
This is a rogue SMM driver. It runs in SMM mode and has access to
confidential SMM data. It saves the address of the SMST for the next
patch, at a known location in the emulated NVRAM.
v3:
- rebased to EmuNvramLib
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
Data is transferred between S3 Suspend and S3 Resume as follows:
S3 Suspend (DXE):
(1) BdsLibBootViaBootOption()
EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe]
- saves ACPI S3 Context to SMRAM LockBox ---+
(including FACS address -- FACS ACPI table |
Exploit that (MemoryBase + MemorySize) always equals LowerMemorySize.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/PlatformPei/MemDetect.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/PlatformPei/MemDetect.c
In the following patches we'll need three kinds of storage that are
reserved from the OS and survive S3 suspend. (Non-volatility across cold
reboot is not needed.) This trivial library ensures that all parties will
have the same notion about where in guest RAM the various sections of the
NVRAM are
This driver (from
"MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf")
is first loaded normally during DXE. When the
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely
as a form of notification), the driver reloads itself to reserved memory.
During
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the library
instance that implements the LockBoxLib library class with SMRAM access
for the PEI phase.
Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and
PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/PlatformPei/Fv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/PlatformPei/Fv.c
index a119172..e309ddf 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/
This internal function allows separation of library-internal and
for-clients external availability of fw_cfg.
The interface contract of QemuFwCfgIsAvailable() is changed so that now it
may modify fw_cfg state. All current users are compliant with the new
contract.
Contributed-under: TianoCore Con
This in turn requires resolving MemoryAllocationLib for DXE_SMM_DRIVERs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf | 1 -
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc
DecompressGuidedFv() should check if the highest address used during
decompression errs into the emulated NVRAM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Sec/SecMain.inf | 1 +
OvmfPkg/Sec/SecMain.c | 6 ++
2 files changed, 7 insertion
"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()
This mostly no-op runtime DXE driver produces the EFI_SMM_ACCESS2_PROTOCOL
and EFI_SMM_CONTROL2_PROTOCOL protocols, enabling the SMM core to be
loaded in the next patch.
v3:
- rebased to EmuNvramLib
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/
Adding the documentation early on should help understand and review the
coming up patches.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/PlatformPei/MemoryMap.txt | 120 ++
1 file changed, 120 insertions(+)
cr
NVRAM emulation has no other purpose than implementing S3 support.
With S3 turned off in the VM configuration, this patch saves over 33 MB of
guest RAM: the 0x0140..0x03501000 range is not reserved any longer;
see "OvmfPkg/PlatformPei/MemoryMap.txt".
The absence of SMRAM (which is part of the
In chronological order (see InitializePlatform()):
normal boot pathS3 Resume boot path
-- --
value of "S3Resume" FALSE TRUE
PublishPeiMemoryNO,
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 prevents further LockBox access.
We cannot install this protocol before BdsLibBoot
On X64, the reset vector code in
"OvmfPkg/ResetVector/Ia32/PageTables64.asm" identity maps the first 4GB of
RAM for PEI, consuming six frames starting at 512KB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/PlatformPei/Fv.c | 12
1 f
"OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf" (originally:
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf")
produces the EFI_ACPI_S3_SAVE_PROTOCOL.
When found, this protocol is automatically invoked by
BdsLibBootViaBootOption(), in file
"IntelFrameworkModulePkg/Library/Generic
v1 posting:
- http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5461
additional v1 test results:
- http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5461/focus=5495
- http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5461/focus=5501
- http://thread.gmane.org/gmane.comp.bios.tiano
Such a packaged query function will come in handy in the following
patches.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Include/Library/QemuFwCfgLib.h | 14 ++
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 28 ++
"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf" produces the
EFI_PEI_S3_RESUME2 PEIM-to-PEIM Interface.
When the platform-specific initialization code (in PEI) sets the Boot Mode
to BOOT_ON_S3_RESUME, the DXE IPL (which is the last step in PEI) skips
the DXE phase entirely, and executes
In the following patches we'll make memory reservations dependent on S3
support (as configured by the host admin for the guest). We must not enter
the S3 boot path without having reserved memory.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Plat
This area is also overwritten by SEC when it decompresses the main
firmware -- tell the OS to stay away.
+--+ 8M (PcdOvmfMemFvBase)
^ | |
final decompr. | +--+ 9M (OutputBuffer)
targe
LockBoxLib has two sets of implementations. The Null implementation (which
is the OVMF default) is not useful for us any longer; we need the library
instances that back the LockBox structure with SMRAM -- the SmmLockBoxLib
variants.
These variants (library instances) are for:
- DXE_DRIVER, DXE_RUN
The low-level data transfer between S3 Suspend and S3 Resume happens thru
SMRAM. SMRAM is theoretically accessible to SMM drivers only; other
("untrusted") drivers can only talk to the former via
EFI_SMM_COMMUNICATION_PROTOCOL.
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" implements the SMM Initial
This area is overwritten after resume / reboot. Make sure the OS steers
clear of it so that we don't destroy OS data after resume.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/PlatformPei/Fv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deleti
One main reason could be your polling functions as UEFI doesn't have
interrupts.
On Tue, Dec 24, 2013 at 5:56 PM, boot devel wrote:
> Hi,
>
> My legacy optionrom driver downloads windows boot image over PXE in few
> seconds but uefi optionrom is taking several minutes, what could be the
> r
Hi,
My legacy optionrom driver downloads windows boot image over PXE in few
seconds but uefi optionrom is taking several minutes, what could be the
reason and any configuration to speed up boot image download?
Driver code is compiled in MdeModulePkg/Bus/Pci/Mydriver
INF file Module_type = DXE_RU
38 matches
Mail list logo
