Increase the section alignment to 4 KB for DXE_RUNTIME_DRIVER modules.
This allows the OS to map them with tightened permissions (i.e., R-X for
.text and RW- for .data). This is a prerequisite for enabling the
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA (sic)
feature that was introduced in UEFIv2.5.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18564 6f19259b-4bc3-4df7-8a09-765794883524
The TFTP command is easy to use, it has very nice documentation
(accessible with "HELP TFTP" in the shell), and it's a very versatile tool
for downloading files from the host to the guest, via virtual network,
while the guest is in the UEFI shell.
Even better, enabling this command in the shell increases the uncompressed
DXEFV size only by 12896 bytes, in my X64 build, and the final size
increase (after LZMA compression) that is visible in the FVMAIN_COMPACT
volume is merely 2576 bytes.
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@18554 6f19259b-4bc3-4df7-8a09-765794883524
In this patch, we replace the traditional IDE driver stack that comes from
PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers
from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible
with the previous one, but provides more protocols, on more kinds of
virtual hardware.
Remove:
- PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
(removing EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
Remove the dependent:
- IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
(removing EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3])
As replacement, add:
- OvmfPkg/SataControllerDxe/SataControllerDxe.inf
(supplying EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
(providing EFI_ATA_PASS_THRU_PROTOCOL,
EFI_EXT_SCSI_PASS_THRU_PROTOCOL)
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
(supplying EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3],
providing EFI_BLOCK_IO2PROTOCOL,
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL)
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[lersek@redhat.com: rewrote commit message]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18532 6f19259b-4bc3-4df7-8a09-765794883524
(PcdSetNxForStack == TRUE) breaks a number of GRUB versions that, it turns
out, are still widely in use. Disable PcdSetNxForStack by default for now.
QEMU users can enable it dynamically using the micro-feature added in the
previous patch.
Reported-by: Anthony Perard <anthony.perard@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18472 6f19259b-4bc3-4df7-8a09-765794883524
Since PcdPropertiesTableEnable is used by the DXE Core (in the
InstallPropertiesTable() function, which runs at End-of-Dxe), we must also
change the PcdLib class resolution for that module, from the default
BasePcdLibNull to DxePcdLib.
Traditionally we've considered the DXE Core to be incapable of accessing
dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core,
and the PCD Protocol is not available to it *yet*. There are exceptions
however: if the DXE Core can ensure, by whatever means, that the PCD
Protocol *is* available, then DxePcdLib will just work (the latter even
lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks
up the PCD Protocol dynamically, on the first library call that actually
needs it (for accessing a dynamic PCD); the lookup doesn't occur in a
library constructor.
And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe,
the PCD Protocol is definitely available then.
In addition, we change the default value of PcdPropertiesTableEnable from
the inherited TRUE to FALSE. It makes no difference at this point (our
runtime DXE drivers are not built with the required 4KB section alignment
anyway), but it's better to be clear about this. The properties table
feature requires OS compatibility, and it breaks Windows 7 minimally.
Therefore the default should be FALSE.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@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@18470 6f19259b-4bc3-4df7-8a09-765794883524
Plus, because PcdSetNxForStack is used by the DXE IPL PEIM (in the
HandOffToDxeCore() function, and in the CreateIdentityMappingPageTables()
function called by the former), we must change the PcdLib class resolution
for that module, from the default BasePcdLibNull to PeiPcdLib.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@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@18469 6f19259b-4bc3-4df7-8a09-765794883524
SVN rev 18166 ("MdeModulePkg DxeIpl: Add stack NX support") enables
platforms to request non-executable stack for the DXE phase, by setting
PcdSetNxForStack to TRUE.
The PCD defaults to FALSE, because:
(a) A non-executable DXE stack is a new feature and causes changes in
behavior. Some platform could rely on executing code from the stack.
(b) The code enabling NX in the DXE IPL PEIM enforces the
PcdSetNxForStack ==> PcdDxeIplBuildPageTables
implication for "64-bit PEI + 64-bit DXE" platforms, with a new
ASSERT(). Some platform might not comply with this requirement
immediately.
Regarding (a), in none of the OVMF builds do we try to execute code from
the stack.
Regarding (b):
- In the OvmfPkgX64.dsc build (which is where (b) applies) we simply
inherit the PcdDxeIplBuildPageTables|TRUE default from
"MdeModulePkg/MdeModulePkg.dec". Therefore we can set PcdSetNxForStack
to TRUE.
- In OvmfPkgIa32X64.dsc, page tables are built by default for DXE. Hence
we can set PcdSetNxForStack to TRUE.
- In OvmfPkgIa32.dsc, page tables used not to be necessary until now.
After we set PcdSetNxForStack to TRUE in this patch, the DXE IPL will
construct page tables even when it is built as part of OvmfPkgIa32.dsc,
provided the (virtual) hardware supports both PAE mode and the XD bit.
Should this setting cause problems in a GPU (or other device) passthru
scenario, with a UEFI_DRIVER in the PCI option rom attempting to execute
code from the stack, the feature can be dynamically disabled on the QEMU
command line, with "-cpu <MODEL>,-nx".
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: "Zeng, Star" <star.zeng@intel.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18360 6f19259b-4bc3-4df7-8a09-765794883524
Since SVN r18316 / git 5ca29abe52, the HTTP driver needs the HTTP
utilities driver to parse the headers of HTTP requests. Add the driver
into OVMF so that the HTTP driver can work properly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18359 6f19259b-4bc3-4df7-8a09-765794883524
Since Variable driver has been updated to consume the separated VarCheckLib.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18281 6f19259b-4bc3-4df7-8a09-765794883524
This commit introdues a new build option to OvmfPkg: HTTP_BOOT_ENABLE.
When HttpBoot is enabled, a new Network boot option will show in the
boot manager menu with the device path like this:
PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)/Uri()
It works like the PXE one but fetches the NBP from the given http
url instead of the tftp service.
A simple testing environment can be set up with the QEMU tap network
and dnsmasq + lighttpd.
Here is the example of the dnsmasq config:
interface=<tap interface>
dhcp-range=192.168.111.100,192.168.111.120,12h
dhcp-option=60,"HTTPClient"
dhcp-boot="http://<tap ip>/<efi file>"
It's similar to the PXE server settings except the tftp function is
disabled, the option 60 must be "HTTPClient", and the boot uri is a
http url.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-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@18258 6f19259b-4bc3-4df7-8a09-765794883524
Also set the DocRev field the way QEMU exposes it, because
MdeModulePkg/Universal/SmbiosDxe lets us control that field too.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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@18182 6f19259b-4bc3-4df7-8a09-765794883524
This dynamic PCD will enable a small code de-duplication between
OvmfPkg/SmbiosPlatformDxe and OvmfPkg/Library/SmbiosVersionLib. Since both
of those are also used in ArmVirtQemu.dsc, and we should avoid
cross-package commits when possible, this patch declares
PcdQemuSmbiosValidated first, and sets defaults for it in the OvmfPkg DSC
files.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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@18178 6f19259b-4bc3-4df7-8a09-765794883524
This patch de-duplicates the logic added in commit
OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically
(git 37baf06b, SVN r17676) by hooking DetectSmbiosVersionLib into
SmbiosDxe.
Although said commit was supposed to work with SMBIOS 3.0 payloads from
QEMU, in practice that never worked, because the size / signature checks
in SmbiosVersionInitialization() would always fail, due to the SMBIOS 3.0
entry point being structurally different. Therefore this patch doesn't
regress OvmfPkg.
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Suggested-by: 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@18175 6f19259b-4bc3-4df7-8a09-765794883524
The source code is copied verbatim, with the following two exceptions:
- the UNI files are dropped, together with the corresponding UNI
references in the INF file,
- the INF file receives a new FILE_GUID.
The OVMF DSC and FDF files are at once flipped to the cloned driver.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17951 6f19259b-4bc3-4df7-8a09-765794883524
Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol,
which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)).
Therefore we can remove Ip4ConfigDxe driver from this build.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17914 6f19259b-4bc3-4df7-8a09-765794883524
AuthVariableLib and TpmMeasurementLib library classes are now linked with
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
to optionally support secure variables.
For OvmfPkg,
link AuthVariableLib and DxeTpmMeasurementLib in SecurityPkg
when SECURE_BOOT_ENABLE = TRUE,
and link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg
when SECURE_BOOT_ENABLE = FALSE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17760 6f19259b-4bc3-4df7-8a09-765794883524
Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to
3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the
version number of the SMBIOS entry point table (and other things) that
"MdeModulePkg/Universal/SmbiosDxe" installs.
Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7);
those are limited to 2.x (both in the guest kernel firmware driver, and in
the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID --
defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and
guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize
it.
The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware
to install. The payload includes the entry point table ("anchor" table).
OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is
the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe"
driver); however, we can parse the entry point version from QEMU's anchor
table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that
version.
On machine types older than v2.1.0, the feature is not available, but
then, should anything in OVMF install SMBIOS tables, version 2.8 is simply
safer / more widely supported than 3.0 -- hence the default 2.8 value for
the dynamic PCD.
We set the PCD in PlatformPei (when not on the S3 resume path), because
that's an easy and certain way to set the PCD before a DXE driver reads
it. This follows the example of PcdEmuVariableNvStoreReserved (which is
read by EmuVariableFvbRuntimeDxe).
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876
Cc: Gabriel Somlo <somlo@cmu.edu>
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>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
QEMU commit aa685789 ("xhci: generate a Transfer Event for each Transfer
TRB with the IOC bit set") fixed an emulation problem in QEMU; we can now
drive that host controller with edk2's XhciDxe. Include it in OvmfPkg, as
XHCI emulation is reportedly more virtualization-friendly than EHCI,
consuming less CPU.
The driver can be tested with the following QEMU command line options:
-device nec-usb-xhci -device usb-kbd
This patch should not regress existing QEMU command lines (ie. trigger an
ASSERT() in XhciDxe that fails on pre-aa685789 QEMU) because QEMU's
"-device nec-usb-xhci" has never before resulted in USB devices that
worked with edk2 firmware builds, hence users have never had a reason to
add that option.
Now that they learn about XHCI support in OVMF by reading this commit
message, they (or their packagers) will also know to update qemu to
aa685789 or later (in practice that means the upcoming 2.3 release), at
least if they want to use '-device nec-usb-xhci' with edk2, for the first
time ever.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Alexander Graf <agraf@suse.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17055 6f19259b-4bc3-4df7-8a09-765794883524
Perform the following renames in order to stick with edk2 tradition more
closely:
XenHypercallLibArm, XenHypercallLibIntel -> XenHypercallLib
XenHypercallIntel -> X86XenHypercall
In addition, we unify the INF files.
This patch modifies ArmVirtualizationPkg and OvmfPkg at once, in order to
keep both bisectable (client code shouldn't break).
Suggested-by: 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>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16998 6f19259b-4bc3-4df7-8a09-765794883524
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16973 6f19259b-4bc3-4df7-8a09-765794883524
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
Move libraries from ShellPkg into MdeModulePkg and MdePkg.
The following libraries are being migrated out of ShellPkg in order to make
their functionality more widely available.
• PathLib: Incorporate into MdePkg/Library/BaseLib
• FileHandleLib: MdePkg/Library/UefiFileHandleLib
• BaseSortLib: MdeModulePkg/Library/BaseSortLib
• UefiSortLib: MdeModulePkg/Library/UefiSortLib
Diffs showing file changes are in the attached file, LibMigration.patch.
A description of the changes follows:
• Move ShellPkg/Include/Library/FileHandleLib.h to MdePkg/Include/Library/FileHandleLib.h
• Move ShellPkg/Include/Library/SortLib.h to MdeModulePkg/Include/Library/SortLib.h
• Move ShellPkg/Library/BaseSortLib to MdeModulePkg/Library/BaseSortLib
• Move ShellPkg/Library/UefiSortLib to MdeModulePkg/Library/UefiSortLib
• Move ShellPkg/Library/BasePathLib/BasePathLib.c to MdePkg/Library/BaseLib/FilePaths.c
• Merge ShellPkg/Include/Library/PathLib.h into MdePkg/Include/Library/BaseLib.h
• Delete ShellPkg/Library/BasePathLib; Includes BasePathLib.c and BasePathLib.inf
• NetworkPkg/NetworkPkg.dsc
• PerformancePkg.dsc
• OvmfPkg/OvmfPkgX64.dsc
• OvmfPkg/OvmfPkgIa32X64.dsc
• OvmfPkg/OvmfPkgIa32.dsc
o Update SortLib and FileHandleLib library classes to point to the new library locations.
o Remove PathLib library class and make sure that BaseLib is described.
• MdeModulePkg/MdeModulePkg.dec
o Add SortLib library class
• MdePkg/MdePkg.dec
o Add FileHandleLib library class
o Add PcdUefiFileHandleLibPrintBufferSize PCD
• MdePkg/Library/BaseLib/BaseLib.inf
o Add FilePaths.c to [Sources]
• MdePkg/Include/Library/BaseLib.h
o Update file description to include "file path functions"
• ShellPkg/ShellPkg.dsc
o Change PACKAGE_GUID to { C1014BB7-4092-43D4-984F-0738EB424DBF }
o Update PACKAGE_VERSION to 1.0
o Update SortLib and FileHandleLib library classes to point to the new library locations.
o Remove PathLib library class and make sure that BaseLib is described.
o Remove ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf from [Components]
• ShellPkg/ShellPkg.dec
o Update PLATFORM_VERSION to 1.0
o Remove declarations of the FileHandleLib, SortLib, and PathLib Library Classes
o Update comment for the PcdShellPrintBufferSize PCD.
• ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
• ShellPkg/Application/Shell/Shell.inf
o Remove PathLib from [LibraryClasses]
• ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
• ShellPkg/Application/Shell/Shell.h
o Remove #include <Library/PathLib.h>
• ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
o Add PathLib to [LibraryClasses]
• ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
o Remove #include <Library/PathLib.h>
• ShellPkg/Application/ShellSortTestApp/ShellSortTestApp.inf
o Add MdeModulePkg/MdeModulePkg.dec to [Packages]
• MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
• MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
o Replace ShellPkg.dec with MdeModulePkg.dec in [Packages]
• MdeModulePkg/Library/UefiSortLib/UefiSortLib.c
o Remove #include <ShellBase.h>
o Define USL_FREE_NON_NULL() to replace SHELL_FREE_NON_NULL()
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel <daryl.mcdaniel@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16601 6f19259b-4bc3-4df7-8a09-765794883524
and rebase OvmfPkg's PlatformBdsLib on the standalone library.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
There are several network stack drivers in MdeModulePkg or NetworkPkg.
Currently, we only use the drivers from MdeModulePkg which only provides
the IPv4 support. This commit adds the IPv6 drivers in NetworkPkg into
OVMF.
Here is the table of drivers from Laszlo.
currently included related driver add or replace
from MdeModulePkg in NetworkPkg from NetworkPkg
------------------ -------------- ---------------
SnpDxe n/a n/a
DpcDxe n/a n/a
MnpDxe n/a n/a
VlanConfigDxe n/a n/a
ArpDxe n/a n/a
Dhcp4Dxe Dhcp6Dxe add
Ip4ConfigDxe Ip6Dxe add
Ip4Dxe Ip6Dxe add
Mtftp4Dxe Mtftp6Dxe add
Tcp4Dxe TcpDxe replace
Udp4Dxe Udp6Dxe add
UefiPxeBcDxe UefiPxeBcDxe replace
IScsiDxe IScsiDxe replace
Since the TcpDxe, UefiPxeBcDxe, and IScsiDxe drivers in NetworkPkg also
support IPv4, we replace the ones in MdeModulePkg.
To enable the IPv6 support, build OVMF with "-D NETWORK_IP6_ENABLE".
A special case is NetworkPkg/IScsiDxe. It requires openssl. For convenience,
NetworkPkg/IScsiDxe is enabled only if both IPv6 and SecureBoot are enabled.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
[lersek@redhat.com: typo fix in commit message; specil -> special]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16543 6f19259b-4bc3-4df7-8a09-765794883524
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against
a valid, non-asserting version of PcdLib, then switch them over to using
the "Dxe" instance of AcpiTimerLib (instead of the "Base" version).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16378 6f19259b-4bc3-4df7-8a09-765794883524
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may
utilize global variables, use the "Base" AcpiTimerLib instance
(instead of BaseRom) to take advantage of the improved efficiency
of storing the timer register IO address in a global variable.
This leaves only SEC using the BaseRomAcpiTimerLib instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16377 6f19259b-4bc3-4df7-8a09-765794883524
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
Set from PEI, this PCD allows subsequent stages (specifically
DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform
type (e.g. PIIX4 or Q35/MCH) without the need to further query the
Host Bridge for its Device ID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16374 6f19259b-4bc3-4df7-8a09-765794883524
On a physical screen such a low graphics resolution would lead to huge
glyphs (the text resolution is 80x25, centered, with 8x19 pixel glyphs).
But in a virtual machine it just saves screen real estate on the client,
by removing the black bands.
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@16311 6f19259b-4bc3-4df7-8a09-765794883524
PlatformBdsEnterFrontPage() already implements a keypress wait (for
entering the setup utility at boot) with a nice progress bar, only OVMF
has not been using it.
Removing our custom code and utilizing PlatformBdsEnterFrontPage()'s
builtin wait has the following benefits:
- It simplifies OVMF's BDS code.
- Because now we call PlatformBdsEnterFrontPage() unconditionally, it
actually has a chance to look at the EFI_OS_INDICATIONS_BOOT_TO_FW_UI
bit of the "OsIndications" variable, improving compliance with the UEFI
specification. References:
- https://bugzilla.redhat.com/show_bug.cgi?id=1153927
- http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10487
- The progress bar looks nice. (And it keeps the earlier behavior intact,
when the user presses a key on the TianoCore splash screen.)
In any case, we set the timeout to 0 (which doesn't show the progress
bar and proceeds to the boot options immediately) in order to keep the
boot time down.
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@16310 6f19259b-4bc3-4df7-8a09-765794883524
A ParaVirtualize block driver.
Change in V4:
- Replace the license by the commonly used file header text.
- Add brief description for the driver.
Change in V3:
- enable compilation for Ia32 and Ia32X64
- fix version (driver binding)
Change in V2:
- Add minimal support for controller name
- Remove stuff about BlockIo2
- Little cleanup
- Licenses and file headers
- Rename XenbusIo into XenBusIo
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16272 6f19259b-4bc3-4df7-8a09-765794883524
This includes Component Name and Driver Binding.
Change in V4:
- Replace the license by the commonly used file header text.
- Add brief description for the driver.
Change in V3:
- enable compilation for Ia32 and Ia32X64
- fix version (driver binding)
Change in V2:
- Simple support of controller name.
- Cleaning up comments, files header.
- Add Licenses
- Rename XenbusDxe to XenBusDxe.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16258 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg forked SecureBootConfigDxe from SecurityPkg in SVN r13635 (git
commit 8c71ec8f). Since then, the original (in
"SecurityPkg/VariableAuthenticated/SecureBootConfigDxe") has diverged
significantly.
The initial diff between the original and the fork, when the fork was made
(ie. at SVN r13635), reads as follows:
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr 2014-08-09 02:40:35.824851626 +0200
> @@ -51,7 +51,7 @@
> questionid = KEY_SECURE_BOOT_ENABLE,
> prompt = STRING_TOKEN(STR_SECURE_BOOT_PROMPT),
> help = STRING_TOKEN(STR_SECURE_BOOT_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
>
> @@ -158,7 +158,7 @@
> questionid = KEY_SECURE_BOOT_DELETE_PK,
> prompt = STRING_TOKEN(STR_DELETE_PK),
> help = STRING_TOKEN(STR_DELETE_PK_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
> endform;
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.577067027 +0200
> @@ -1,5 +1,8 @@
> ## @file
> -# Component name for SecureBoot configuration module.
> +# Component name for SecureBoot configuration module for OVMF.
> +#
> +# Need custom SecureBootConfigDxe for OVMF that does not force
> +# resets after PK changes since OVMF doesn't have persistent variables
> #
> # Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.<BR>
> # This program and the accompanying materials
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.599067153 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.578067033 +0200
> @@ -2559,7 +2559,7 @@
> NULL
> );
> } else {
> - *ActionRequest = EFI_BROWSER_ACTION_REQUEST_RESET;
> + *ActionRequest = EFI_BROWSER_ACTION_REQUEST_SUBMIT;
> }
> break;
The commit message is not overly verbose:
OvmfPkg: Add custom SecureBootConfigDxe that doesn't reset
We don't force a platform reset for OVMF when PK is changed in custom
mode setup.
But the INF file hunk is telling:
Need custom SecureBootConfigDxe for OVMF that does not force resets
after PK changes since OVMF doesn't have persistent variables
We do have persistent variables now. Let's disable the (now obsolete)
OvmfPkg fork, and revert to the (well maintained) SecurityPkg-provided
config driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gary Lin <glin@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16191 6f19259b-4bc3-4df7-8a09-765794883524
The "complete" QEMU fw_cfg ACPI loader will need to look up downloaded
blobs by name, in order to implement the AddPointer and AddChecksum
commands. Introduce OrderedCollectionLib to support such indexing.
BaseOrderedCollectionRedBlackTreeLib is a BASE module, hence add the
OrderedCollectionLib resolution to the main [LibraryClasses] section.
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@16155 6f19259b-4bc3-4df7-8a09-765794883524
SVN r16092 ('ShellPkg: Add a new library for "bcfg" command') introduced a
new library class (and an instance for it) called BcfgCommandLib.
SVN r16093 ('ShellPkg: Use the new library for "bcfg" command') rebased
ShellPkg to the new library, introducing a new [LibraryClasses]
dependency.
Library classes must be resolved to library instances in client platform
descriptions (DSC's). Since OVMF is a client platform, import the same
library resolution as seen in "ShellPkg/ShellPkg.dsc" (added in SVN
r16092).
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@16095 6f19259b-4bc3-4df7-8a09-765794883524
VideoDxe is a UEFI_DRIVER, so it has by default a null instance
of PcdLib. It accesses two PCDs that are now dynamic
(gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
and gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution).
Similar to r15362 (OvmfPkg: non-null PcdLib instance for
GraphicsConsoleDxe, 2014-03-22), we need to specify a non-null
instance of PcdLib.
This patch unbreaks the CSM VideoDxe module for OvmfPkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-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@15421 6f19259b-4bc3-4df7-8a09-765794883524
This DXE driver will load/save persistent values for OVMF's config knobs,
plus expose those knobs via HII.
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@15364 6f19259b-4bc3-4df7-8a09-765794883524
GraphicsConsoleDxe (a UEFI_DRIVER under MdeModulePkg/Universal/Console)
determines the preferred video resolution from the dynamic PCDs
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
In one of the next patches, we'd like to change these PCDs. In order for
GraphicsConsoleDxe to retrieve the new values dynamically,
- it must be linked with the non-null instance of PcdLib,
- OvmfPkg must provide dynamic defaults.
We keep MdeModulePkg's 800x600 default resolution. (The UEFI specification
requires video drivers to support 800x600.)
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@15362 6f19259b-4bc3-4df7-8a09-765794883524
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 S3 Resume / PEI, the driver image is executed from there. In order
to access the boot script saved during S3 Suspend, LockBox access is
needed.
The boot script is transferred internal to PiDxeS3BootScriptLib:
Both S3SaveStateDxe and BootScriptExecutorDxe are statically linked
against PiDxeS3BootScriptLib. Whichever is loaded first (during normal
boot, in the DXE phase), allocates the root storage for the script. The
address is then passed between the PiDxeS3BootScriptLib instances living
in the two separate drivers thru the dynamic
PcdS3BootScriptTablePrivateDataPtr PCD.
Dependencies:
BootScriptExecutorDxe
gEfiLockBoxProtocolGuid [OvmfPkg/AcpiS3SaveDxe]
S3BootScriptLib [PiDxeS3BootScriptLib]
SmbusLib [BaseSmbusLibNull]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
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@15307 6f19259b-4bc3-4df7-8a09-765794883524
"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.
S3SaveStateDxe relies on the S3BootScriptLib library. The Null
implementation is not useful for actually saving the boot script, we need
the PiDxeS3BootScriptLib instance.
The PiDxeS3BootScriptLib library instance depends on LockBoxLib,
implemented for OVMF in one of the previous patches.
PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null
instance of the latter. It means that SMBus commands in the boot script
will have no effect when interpreted during S3 Resume. This should be fine
for OvmfPkg and QEMU.
EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe]
S3BootScriptLib [PiDxeS3BootScriptLib]
SmbusLib [BaseSmbusLibNull]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver
(purely as a form of notification), the S3SaveStateDxe driver saves the
boot script to EfiACPIMemoryNVS, and links it into the LockBox.
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@15304 6f19259b-4bc3-4df7-8a09-765794883524
"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/GenericBdsLib/BdsBoot.c", right before
booting a boot option, to save ACPI S3 context.
At that point during BDS, our AcpiPlatformDxe driver will have installed
the FACS table (which AcpiS3SaveDxe has a use-time dependency upon).
With regard to dependencies: AcpiS3SaveDxe implements
EFI_ACPI_S3_SAVE_PROTOCOL by relying on LockBoxLib.
BdsLibBootViaBootOption()
EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: Remove EmuNvramLib]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15303 6f19259b-4bc3-4df7-8a09-765794883524
The S3 suspend/resume infrastructure depends on the LockBox library class.
The edk2 tree currently contains Null and SMM instances. The Null instance
is useless, and the SMM instance would require SMM emulation by including
the SMM core and adding several new drivers, which is deemed too complex.
Hence add a simple LockBoxLib instance for OVMF.
jordan.l.justen@intel.com:
* use PCDs instead of EmuNvramLib
- clear memory in PlatformPei on non S3 boots
* allocate NVS memory and store a pointer to that memory
- reduces memory use at fixed locations
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15301 6f19259b-4bc3-4df7-8a09-765794883524
"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 the S3 Resume PEIM through the
EFI_PEI_S3_RESUME2 interface instead. (See DxeLoadCore() in
"MdeModulePkg/Core/DxeIplPeim/DxeLoad.c".)
S3Resume2Pei depends on LockBoxLib.
EFI_PEI_S3_RESUME2 [S3Resume2Pei]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
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@15300 6f19259b-4bc3-4df7-8a09-765794883524
The Linux persistent store (pstore) feature serves, among other things,
for saving the trailing portion of the dmesg in case of a kernel oops. One
backend for the pstore facility is "efivars", ie. non-volatile UEFI
variables.
Linux splits the tail of the dmesg that is to be dumped in 1KB chunks, and
tries to save each chunk as a specially (and differently) named
non-volatile variable. The 1KB chunk size accounts for the variable data
only; Linux expects this size to be available per variable *without*
accounting for the variable name or any firmware-internal overhead.
For non-authenticated (ie. non-secure-boot) variables, OvmfPkg currently
sets the per-variable limit to 0x400 (1KB) through PcdMaxVariableSize.
However this PCD determines the size *before* subtracting the internal
overhead (which is sizeof(VARIABLE_HEADER) == 0x20 bytes for
non-authenticated variables, see
"MdeModulePkg/Include/Guid/VariableFormat.h"), and also before subtracting
the given variable's UCS-2 encoded name (including the trailing 0x0000).
Linux maximizes these special variable names in DUMP_NAME_LEN==52 code
points (including the trailing NUL). Hence we must provide at least
0x020 == sizeof(VARIABLE_HEADER), for the internal overhead
0x068 == 2 * 52, for the UCS-2 encoded name, including trailing 0x0000
0x400 for the variable body
-----
0x488 == 1160
bytes in PcdMaxVariableSize, so that Linux's efivars-backed pstore can
work even on non-secure-boot builds of OVMF.
However, as PcdMaxVariableSize=0x2000 has proven reasonable when secure
boot is enabled, it should also be okay when secure boot is disabled; so
for simplicity's sake set PcdMaxVariableSize to 0x2000 unconditionally.
Tested-by: Seiji Aguchi <seiji.aguchi@hds.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@15142 6f19259b-4bc3-4df7-8a09-765794883524
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-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@15046 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel
Laszlo Ersek
Reza Jelveh
Gary Ching-Pang Lin
Star Zeng
Jiaxin Wu
Ruiyu Ni
Daryl McDaniel
Gabriel Somlo
Anthony PERARD
Jordan Justen
Paolo Bonzini