summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgIa32X64.fdf
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: add driver for Virtio-RNG deviceArd Biesheuvel2016-02-241-0/+1
| | | | | | | | | | | This adds the new Virtio-RNG DXE module to all three builds of OvmfPkg. Note that QEMU needs to be invoked with the 'device virtio-rng-pci' option in order for this device to be exposed to the guest. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include NvmExpressDxe driverLaszlo Ersek2016-02-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | QEMU emulates NVMe. NvmExpressDxe seems to work well with it. The relevant QEMU options are -drive id=drive0,if=none,format=FORMAT,file=PATHNAME \ -device nvme,drive=drive0,serial=SERIAL where the required SERIAL value sets the Serial Number (SN) field of the "Identify Controller Data Structure". It is an ASCII string with up to 20 characters, which QEMU pads with spaces to maximum length. (Refer to "NVME_ADMIN_CONTROLLER_DATA.Sn" in "MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h".) Cc: Vladislav Vovchenko <vladislav.vovchenko@sk.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reference: https://github.com/tianocore/edk2/issues/48 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: Vladislav Vovchenko <vladislav.vovchenko@sk.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19791 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Increase default RELEASE build image size to 2MBJordan Justen2016-01-291-12/+0
| | | | | | | | | | | | Fixes: https://github.com/tianocore/edk2/issues/47 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Bruce Cran <bruce@cran.org.uk> Cc: Laszlo Ersek <lersek@redhat.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@19775 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: pull in SMM-based variable driver stackLaszlo Ersek2015-11-301-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | When -D SMM_REQUIRE is given, replace both - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and - OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf with - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf. The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and the rest: - the privileged half of the variable driver, VariableSmm, - the fault tolerant write driver, FaultTolerantWriteSmm, - and the FVB driver, FvbServicesSmm, work in SMM purely. We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the authenticated VariableSmm driver's sake. 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@19065 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: consolidate variable driver stack in DSC and FDF filesLaszlo Ersek2015-11-301-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | The following modules constitute the variable driver stack: - QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime alternatives for providing the Firmware Volume Block(2) Protocol, dependent on qemu pflash presence, - FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol, - MdeModulePkg/Universal/Variable/RuntimeDxe, independently of -D SECURE_BOOT_ENABLE, providing the Variable and Variable Write Architectural Protocols. Let's move these drivers closer to each other in the DSC and FDF files, so that we can switch the variable driver stack to SMM with more local changes. 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@19064 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | At this point we can enable building PiSmmCpuDxeSmm. CPU specific features, like SMRR detection, and functions that are used to initialize SMM and process SMIs, are abstracted through the SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with QEMU's and KVM's 64-bit state save map format, which follows the definition from AMD's programmer manual. SmmCpuPlatformHookLib provides platform specific functions that are used to initialize SMM and process SMIs. Resolve it to the one Null instance provided by UefiCpuPkg, which is expected to work for most platforms. Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [pbonzini@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own instance] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19061 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PiSmmCpuDxeSmm driver from UefiCpuPkg depends on the ACPI_CPU_DATA structure -- created by a platform- and CPU-specific driver -- in order to support ACPI S3. The address of this structure is communicated through the dynamic PCD PcdCpuS3DataAddress. The "UefiCpuPkg/Include/AcpiCpuData.h" header file documents the fields of this structure in detail. The simple/generic "UefiCpuPkg/CpuS3DataDxe" driver creates and populates the structure in a conformant way, and it co-operates well with PiSmmCpuDxeSmm, for OVMF's purposes. PlatformBdsLib CpuS3DataDxe PiSmmCpuDxeSmm S3Resume2Pei (DXE_DRIVER) (DXE_DRIVER) (DXE_SMM_DRIVER) (PEIM) -------------- --------------- ---------------- -------------- normal collects data boot except MTRR settings into ACPI_CPU_DATA sets PcdCpuS3Da... signals End-of-Dxe | +----------> collects MTRR settings into ACPI_CPU_DATA installs [Dxe]Smm ReadyToLock | +---------------------------> fetches PcdCpuS3Dat... copies ACPI_CPU_DATA into SMRAM runtime S3 suspend S3 transfers resume control to PiSmmCpuDxe... | uses <----+ ACPI_CPU_DATA from SMRAM Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19060 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: pull in CpuIo2Smm driverLaszlo Ersek2015-11-301-0/+9
| | | | | | | | | | | | | | | This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends on in its gEfiDxeSmmReadyToLockProtocolGuid callback (SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c"). Approached on a higher level, this driver provides the SmmIo member of the EFI_SMM_SYSTEM_TABLE2 (SMST). 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@19044 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: pull in the SMM IPL and SMM coreLaszlo Ersek2015-11-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER) implements the SMM Initial Program Loader. It produces EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on: - EFI_SMM_ACCESS2_PROTOCOL (provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf), - EFI_SMM_CONTROL2_PROTOCOL (provided by OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf). (The SMM IPL also depends on EFI_SMM_CONFIGURATION_PROTOCOL_GUID, but this dependency is not enforced in the entry point. A protocol notify callback is registered instead, hence we can delay providing that protocol via the PiSmmCpuDxeSmm driver that is (to be) imported from UefiCpuPkg/.) The SMM IPL loads the SMM core into SMRAM and executes it from there. Therefore we add the SMM core to the build as well. For the SMM core, a number of library classes need to be resolved. Furthermore, each FDF file must provide the GenFds.py BaseTools utility with a build rule for SMM_CORE; we copy the DXE_CORE's rule. 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@19043 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVERLaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function [MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c]. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19042 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXELaszlo Ersek2015-11-301-0/+4
| | | | | | | | | | | | | | | The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which is a thin wrapper around "OvmfPkg/SmmAccess/SmramInternal.c" that was added in the previous patch) provides that protocol. Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore our MODULE_TYPE is not DXE_RUNTIME_DRIVER. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19041 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEILaszlo Ersek2015-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the LockBoxLib instance with SMRAM access for the PEI phase. Said library instance must, and can, access the LockBox data in SMRAM directly if it is invoked before SMBASE relocation / SMI handler installation. In that case, it only needs PEI_SMM_ACCESS_PPI from the platform, and it doesn't depend on EFI_PEI_SMM_COMMUNICATION_PPI. OVMF satisfies the description in SVN r18823 ("MdeModulePkg: SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI"): in OVMF, only S3Resume2Pei links against SmmLockBoxPeiLib. Therefore, introduce a PEIM that produces the PEI_SMM_ACCESS_PPI interface, enabling SmmLockBoxPeiLib to work; we can omit including "UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf". The load / installation order of S3Resume2Pei and SmmAccessPei is indifferent. SmmAccessPei produces the gEfiAcpiVariableGuid HOB during its installation (which happens during PEI), but S3Resume2Pei accesses the HOB only when the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI. MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to prevent VS20xx from warning about the (otherwise fully intentional) truncation in the UINT8 casts. (Warnings reported by Michael Kinney.) Cc: Michael Kinney <michael.d.kinney@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: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19040 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Sec: assert the build-time calculated end of the scratch bufferLaszlo Ersek2015-11-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more memory, temporarily, than what PEIFV and DXEFV will ultimately need. First, it uses an output buffer for decompression, second, the decompression itself needs a scratch buffer (and this scratch buffer is the highest area that SEC uses). DecompressMemFvs() used to be called on normal boots only (ie. not on S3 resume), which is why the decompression output buffer and the scratch buffer were allowed to scribble over RAM. However, we'll soon start to worry during S3 resume that the runtime OS might tamper with the pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3 resume too, from pristine flash. For this we'll need to know the end of the scratch buffer in advance, so we can prepare a non-malicious OS for it. Calculate the end of the scratch buffer statically in the FDF files, and assert in DecompressMemFvs() that the runtime decompression will match it. 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@19036 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: raise DXEFV size to 9 MBGary Ching-Pang Lin2015-10-071-3/+3
| | | | | | | | | | | | | | | | | With gcc5 and enabling SECURE_BOOT and NETWORK_IP6, the build failed with this error: GenFv: ERROR 3000: Invalid the required fv image size 0x814c18 exceeds the set fv image size 0x800000 Raise the DXEFV size to 9 MB to fix the build error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18577 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: enable SATA controllerReza Jelveh2015-09-221-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: Build HTTP utilities driverGary Ching-Pang Lin2015-08-281-0/+1
| | | | | | | | | | | | Since SVN r18316 / git 5ca29abe5297, 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
* OvmfPkg: Add HttpBoot supportGary Ching-Pang Lin2015-08-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: clone PciHostBridgeDxe from PcAtChipsetPkgLaszlo Ersek2015-07-141-1/+1
| | | | | | | | | | | | | | | | | 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
* OvmfPkg: Remove Ip4ConfigDxe module from OvmfPkgJiaxin Wu2015-07-101-1/+0
| | | | | | | | | | | | 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
* OvmfPkg: Fix GCC49 build hang in PeiCoreRuiyu Ni2015-07-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PeiCore hang when loads a PEIM whose section alignment requirement is 0x40 but the actual base address is 0x20 aligned. The issue is caused by the following facts, in order: 1. GCC49 requires the section alignment of .data to be 0x40. So a new link script gcc4.9-ld-script was added for GCC49 to specify the 0x40 alignment. 2. GenFw tool was enhanced to sync ELF's section alignment to PE header. Before the enhancement, the section alignment of converted PE image always equals to 0x20. If only with #1 change, GCC49 build image won't hang in PeiCore because the converted PE image still claims 0x20 section alignment which is aligned to the align setting set in FDF file. But later with #2 change, the converted PE image starts to claims 0x40 section alignment, while build tool still puts the PEIM in 0x20 aligned address, resulting the PeCoffLoaderLoadImage() reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Use the merged Variable driverStar Zeng2015-07-011-4/+2
| | | | | | | | | | 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@17767 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: include XHCI driverLaszlo Ersek2015-03-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOLArd Biesheuvel2015-02-281-0/+1
| | | | | | | | | | | | | | | | 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
* OvmfPkg: enable the IPv6 supportGary Lin2014-12-191-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg/XenPvBlkDxe: Xen PV Block device, initial skeletonAnthony PERARD2014-10-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: Add basic skeleton for the XenBus bus driver.Anthony PERARD2014-10-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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: disable stale fork of SecureBootConfigDxeLaszlo Ersek2014-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: Build OVMF ResetVector during EDK II build processJordan Justen2014-08-181-3/+3
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15824 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fdLaszlo Ersek2014-07-221-20/+34
| | | | | | | | | | | | | | | | | | OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: extract varstore-related FD Layout Regions to an include fileLaszlo Ersek2014-07-221-66/+1
| | | | | | | | | | | | This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. 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@15669 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3Laszlo Ersek2014-04-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF's SecMain is unique in the sense that it links against the following two libraries *in combination*: - IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/ LzmaCustomDecompressLib.inf - MdePkg/Library/BaseExtractGuidedSectionLib/ BaseExtractGuidedSectionLib.inf The ExtractGuidedSectionLib library class allows decompressor modules to register themselves (keyed by GUID) with it, and it allows clients to decompress file sections with a registered decompressor module that matches the section's GUID. BaseExtractGuidedSectionLib is a library instance (of type BASE) for this library class. It has no constructor function. LzmaCustomDecompressLib is a compatible decompressor module (of type BASE). Its section type GUID is gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor function is executed, which registers its LZMA decompressor with the above GUID, by calling into BaseExtractGuidedSectionLib: LzmaDecompressLibConstructor() [GuidedSectionExtraction.c] ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c] GetExtractGuidedSectionHandlerInfo() PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS Later, during a normal (non-S3) boot, SecMain utilizes this decompressor to get information about, and to decompress, sections of the OVMF firmware image: SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c] SecStartupPhase2() FindAndReportEntryPoints() FindPeiCoreImageBase() DecompressMemFvs() ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c] ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c] Notably, only the extraction depends on full-config-boot; the registration of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI binary, triggered by the library constructor function. This is where the bug happens. BaseExtractGuidedSectionLib maintains the table of GUIDed decompressors (section handlers) at a fixed memory location; selected by PcdGuidedExtractHandlerTableAddress (declared in MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB). This causes SecMain to corrupt guest OS memory during S3, leading to random crashes. Compare the following two memory dumps, the first taken right before suspending, the second taken right after resuming a RHEL-7 guest: crash> rd -8 -p 1000000 0x50 1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3.............. 1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8....... 1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo 1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so......... vs. crash> rd -8 -p 1000000 0x50 1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... ....... 1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ............... 1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{.... 1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo 1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so......... The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE declared in MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c. Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at guest-phys offset 0x1000020. Fix the problem as follows: - Carve out 4KB from the 36KB gap that we currently have between PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB and PcdOvmfSecPeiTempRamBase == 8256 KB. - Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000). - Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is supported and we're not currently resuming. The 4KB size that we pick is an upper estimate for BaseExtractGuidedSectionLib's internal storage size. The latter is calculated as follows (see GetExtractGuidedSectionHandlerInfo()): sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32 PcdMaximumGuidedExtractHandler * ( sizeof(GUID) + // 16 sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8 sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8 ) OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes. Regarding the lifecycle of the new area: (a) when and how it is initialized after first boot of the VM The library linked into SecMain finds that the area lacks the signature. It initializes the signature, plus the rest of the structure. This is independent of S3 support. Consumption of the area is also limited to SEC (but consumption does depend on full-config-boot). (b) how it is protected from memory allocations during DXE It is not, in the general case; and we don't need to. Nothing else links against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area. (c) how it is protected from the OS When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions(). When S3 is not supported, the range is not protected. (d) how it is accessed on the S3 resume path Examined by the library linked into SecMain. Registrations update the table in-place (based on GUID matches). (e) how it is accessed on the warm reset path If S3 is enabled, then the OS won't damage the table (due to (c)), hence see (d). If S3 is unsupported, then the OS may or may not overwrite the signature. (It likely will.) This is identical to the pre-patch status. 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@15433 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce empty PlatformDxeLaszlo Ersek2014-03-221-0/+1
| | | | | | | | | | | 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
* OvmfPkg: raise DXEFV size to 8 MBLaszlo Ersek2014-03-051-3/+3
| | | | | | | | | | | | | | | | | | This fixes build errors like: GenFds.py... the required fv image size 0x71b118 exceeds the set fv image size 0x700000 which is reported at least for: (a) -b DEBUG -D SECURE_BOOT_ENABLE -t GCC44, (b) -b DEBUG -D SECURE_BOOT_ENABLE -t GCC48 -D CSM_ENABLE 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@15309 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: S3 Resume: pull in BootScriptExecutorDxeLaszlo Ersek2014-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot ScriptLaszlo Ersek2014-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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: S3 Suspend: save ACPI contextLaszlo Ersek2014-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* OvmfPkg: implement LockBoxLibLaszlo Ersek2014-03-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: S3 Resume: pull in PEIM orchestrating S3 ResumeLaszlo Ersek2014-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | "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
* OvmfPkg: Add section of memory to use for PEI on S3 resumeJordan Justen2014-03-041-0/+3
| | | | | | | | | | | | | | | | | This 32k section of RAM will be declared to the PEI Core on S3 resume to allow memory allocations during S3 resume PEI. If the boot mode is BOOT_ON_S3_RESUME, then we publish the pre-reserved PcdS3AcpiReservedMemory range to PEI. If the boot mode is not BOOT_ON_S3_RESUME, then we reserve this range as ACPI NVS so the OS will not use it. 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@15294 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Split MAINFV into a separate PEI and DXE FVsJordan Justen2014-01-211-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By splitting the PEI and DXE phases into separate FVs, we can only reserve the PEI FV for ACPI S3 support. This should save about 7MB. Unfortunately, this all has to happen in a single commit. DEC: * Remove PcdOvmfMemFv(Base|Size) * Add PcdOvmfPeiMemFv(Base|Size) * Add PcdOvmfDxeMemFv(Base|Size) FDF: * Add new PEIFV. Move PEI modules here. * Remove MAINFV * Add PEIFV and DXEFV into FVMAIN_COMPACT - They are added as 2 sections of a file, and compressed together so they should retain good compression * PcdOvmf(Pei|Dxe)MemFv(Base|Size) are set SEC: * Find both the PEI and DXE FVs after decompression. - Copy them separately to their memory locations. Platform PEI driver: * Fv.c: Publish both FVs as appropriate * MemDetect.c: PcdOvmfMemFv(Base|Size) => PcdOvmfDxeMemFv(Base|Size) OVMF.fd before: Non-volatile data storage FVMAIN_COMPACT uncompressed FV FFS file LZMA compressed MAINFV uncompressed individual PEI modules uncompressed FV FFS file compressed with PI_NONE DXEFV uncompressed individual DXE modules uncompressed SECFV uncompressed OVMF.fd after: Non-volatile data storage FVMAIN_COMPACT uncompressed FV FFS file LZMA compressed PEIFV uncompressed individual PEI modules uncompressed DXEFV uncompressed individual DXE modules uncompressed SECFV uncompressed 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@15151 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000Jordan Justen2014-01-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Note: The Temporary RAM memory size is being reduced from 64KB to 32KB. This still appears to be more than adequate for OVMF's early PEI phase. We will be adding another 32KB range of RAM just above this range for use on S3 resume. The range is declared as part of MEMFD, so it is easier to identify the memory range. We also now assign PCDs to the memory range. The PCDs are used to set the initial SEC/PEI stack in SEC's assembly code. The PCDs are also used in the SEC C code to setup the Temporary RAM PPI. 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@15147 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg X64 ResetVector: Move page tables from 512KB to 8MBJordan Justen2014-01-211-0/+3
| | | | | | | | | | | | | | | | | | To help consolidate OVMF fixed memory uses, we declare this range in MEMFD and thereby move it to 8MB. We also now declare the table range in the FDF to set PCDs. This allows us to ASSERT that CR3 is set as expected in OVMF SEC. OvmfPkgIa32.fdf and OvmfPkgIa32X64.fdf are updated simply for consistency. 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@15146 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Carve 128KB out of MAINFV in MEMFDJordan Justen2014-01-211-3/+4
| | | | | | | | | | | | | In an effort to consolidate fixed memory used by OVMF, we'll move 2 SEC/PEI phase RAM users to 8MB. * X64 page tables (24KB) 0x80000 => 0x800000 * PEI temporary RAM (64KB) 0x70000 => 0x810000 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@15144 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Make the VirtIo devices use the new VIRTIO_DEVICE_PROTOCOLOlivier Martin2013-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change replaces the accesses to the PCI bus from the Block, Scsi and Net drivers by the use of the new VIRTIO_DEVICE_PROTOCOL protocol that abstracts the transport layer. It means these drivers can be used on PCI and MMIO transport layer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - VirtioFlush(): update comment block in VirtioLib.[hc]; error code is propagated from VirtIo->SetQueueNotify(). - VirtioBlkInit(): jump to Failed label if SetPageSize() fails - VirtioBlkInit(): fixup comment, and add error handling, near SetQueueNum() call - VirtioBlkDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_BLOCK_DEVICE; VirtioBlkDriverBindingSupported() handles it already - VirtioNetGetFeatures(): update stale comment block - VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded loop) - VirtioNetDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_NETWORK_CARD; VirtioNetDriverBindingSupported() handles it already - VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation - VirtioNetInitialize(): fix destination error label for when SetPageSize() fails - VirtioScsi.c: fix comment block of VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ() - VirtioScsiInit(): fix destination error label for when SetPageSize() fails - VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation 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@14966 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add QemuFlashFvbServicesRuntimeDxe to firmware imageJordan Justen2013-11-121-0/+2
| | | | | | | | | | | | | | | | This driver will support a flash FVB implementation if QEMU flash is detected. The driver is added to the apriori list to make sure it runs before the EmuVariableFvbRuntimeDxe driver. If this driver detects flash support, then it will disable the EmuVariableFvbRuntimeDxe driver by setting PcdFlashNvStorageVariableBase64. 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@14840 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add NV Variable storage within FDJordan Justen2013-11-121-12/+82
| | | | | | | | | | | | | | | | | | | | | | | | This is to prepare for QEMU flash support which will allow non-volatile variables to be saved in the flash image. Note two size changes: * NV Varstore size increased from 0xc000 to 0xe000 * FTW work size decreased from 0x2000 to 0x1000 The reason for this change is that the fault-tolerant write support requires that the work area fit within the block just before the fault-tolerant write spare storage blocks. Since QEMU flash blocks have a size of 0x1000, this means that the maximum FTW work size is 0x1000. v2: * Update commit message and PcdVariableStoreSize 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@14835 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Increase DEBUG build size to 2MB by defaultJordan Justen2013-11-121-0/+14
| | | | | | | | | | | | | | | | | | | The 1MB image with full debug and the shell included is too large to implement flash based non-volatile variable. After this change, building with -D FD_SIZE_1MB will force the smaller flash size. The default size for RELEASE build remains at 1MB, so using -b RELEASE on the build command line will result in a 1MB flash size. For RELEASE builds -D FD_SIZE_2MB can be used to produce a 2MB flash image. 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@14833 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Build and use the UEFI shell by defaultJordan Justen2013-08-231-5/+1
| | | | | | | | | | | | | | | | Previously OVMF included the older EFI shell binary when building. Now we will build and use the UEFI shell (ShellPkg) instead. v2: * Don't bother building UEFI shell when USE_OLD_SHELL is defined * Fix errors in OvmfPkgIa32X64.fdf 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@14600 6f19259b-4bc3-4df7-8a09-765794883524
* Update OVMF platform to use new display engine and browser.Eric Dong2013-08-121-0/+1
| | | | | | | | | Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@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@14541 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 12:17:47 +0000