summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgIa32.fdf
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/PvScsiDxe: Create empty driverLiran Alon2020-03-301-0/+3
| | | | | | | | | | | In preparation for support booting from PvScsi devices, create a basic scaffolding for a driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-2-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg: give more telling names to some FDF include filesLaszlo Ersek2020-03-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Leif suggested that FDF include files should preferably refer with their names to the FDF file sections from which they are included. Therefore - rename "OvmfPkg.fdf.inc" to "OvmfPkgDefines.fdf.inc" (included from the [Defines] section), - rename "DecomprScratchEnd.fdf.inc" to "FvmainCompactScratchEnd.fdf.inc" (included under the [FV.FVMAIN_COMPACT] section). Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: http://mid.mail-archive.com/20200312142006.GG23627@bivouac.eciton.net Ref: https://edk2.groups.io/g/devel/message/55812 Suggested-by: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200312223555.29267-3-lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: include FaultTolerantWritePei and VariablePei with -D SMM_REQUIRELaszlo Ersek2020-03-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FaultTolerantWritePei consumes: - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase. VariablePei consumes: - PcdFlashNvStorageVariableBase64. Due to the previous patches in this series, the above PCDs are available in the PEI phase, in the SMM_REQUIRE build. FaultTolerantWritePei produces a GUID-ed HOB with FAULT_TOLERANT_WRITE_LAST_WRITE_DATA as contents. It also installs a Null PPI that carries the same gEdkiiFaultTolerantWriteGuid as the HOB. VariablePei depends on the Null PPI mentioned above with a DEPEX, consumes the HOB (which is safe due to the DEPEX), and produces EFI_PEI_READ_ONLY_VARIABLE2_PPI. This enables read-only access to non-volatile UEFI variables in the PEI phase, in the SMM_REQUIRE build. For now, the DxeLoadCore() function in "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c" will not access the "MemoryTypeInformation" variable, because OVMF's PlatformPei always produces the MemoryTypeInformation HOB. (Note: when the boot mode is BOOT_ON_S3_RESUME, PlatformPei doesn't build the HOB, but that's in sync with DxeLoadCore() also not looking for either the HOB or the UEFI variable.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-5-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: raise DXEFV size to 12 MBLaszlo Ersek2020-03-111-3/+3
| | | | | | | | | | | | | | | | Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years, and we've outgrown DXEFV again. Increase the DXEFV size to 12MB now. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2585 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310175025.18849-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: add new QEMU kernel image loader componentsArd Biesheuvel2020-03-051-0/+1
| | | | | | | | | | Add the components that expose the QEMU abstract loader file system so that we can switch over our PlatformBmLib over to it in a subsequent patch. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: clone CpuS3DataDxe from UefiCpuPkgLaszlo Ersek2020-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The @file comments in UefiCpuPkg/CpuS3DataDxe say, [...] It also only supports the number of CPUs reported by the MP Services Protocol, so this module does not support hot plug CPUs. This module can be copied into a CPU specific package and customized if these additional features are required. [...] The driver is so small that the simplest way to extend it with hotplug support is indeed to clone it at first. In this patch, customize the driver only with the following no-op steps: - Update copyright notices. - Update INF_VERSION to the latest INF spec version (1.29). - Update FILE_GUID. - Drop the UNI files. - Replace EFI_D_VERBOSE with DEBUG_VERBOSE, to appease "PatchCheck.py". This patch is best reviewed with: $ git show --find-copies-harder Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-15-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driverLaszlo Ersek2020-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new SMM driver skeleton that registers a root SMI handler, and checks if the SMI control value (written to 0xB2) indicates a CPU hotplug SMI. QEMU's ACPI payload will cause the OS to raise a broadcast SMI when a CPU hotplug event occurs, namely by writing value 4 to IO Port 0xB2. In other words, control value 4 is now allocated for this purpose; introduce the ICH9_APM_CNT_CPU_HOTPLUG macro for it. The standard identifiers in this driver use the new MM (Management Mode) terminology from the PI spec, not the earlier SMM (System Management Mode) terms. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: include TcgDxe moduleMarc-André Lureau2020-03-041-0/+1
| | | | | | | | | | Mirrors TPM 2.0 commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module", 2018-03-09). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-5-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: include TcgPei moduleMarc-André Lureau2020-03-041-0/+1
| | | | | | | | | | Mirrors TPM 2.0 commit 4672a4892867 ("OvmfPkg: include Tcg2Pei module", 2018-03-09). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-4-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: rename TPM2 config prefix to TPMMarc-André Lureau2020-03-041-4/+4
| | | | | | | | | | | A following patch is going to use the same configuration for TPM1.2 and TPM2.0, and it's simpler to support both than variable configurations. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-2-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg IA32: add support for loading X64 imagesArd Biesheuvel2020-03-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | This is the UEFI counterpart to my Linux series which generalizes mixed mode support into a feature that requires very little internal knowledge about the architecture specifics of booting Linux on the part of the bootloader or firmware. Instead, we add a .compat PE/COFF header containing an array of PE_COMPAT nodes containing <machine type, entrypoint> tuples that describe alternate entrypoints into the image for different native machine types, e.g., IA-32 in a 64-bit image so it can be booted from IA-32 firmware. This patch implements the PE/COFF emulator protocol to take this new section into account, so that such images can simply be loaded via LoadImage/StartImage, e.g., straight from the shell. This feature is based on the EDK2 specific PE/COFF emulator protocol that was introduced in commit 57df17fe26cd ("MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images", 2019-04-14). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add the 'initrd' dynamic shell commandArd Biesheuvel2020-03-041-0/+1
| | | | | | | | | | Add the 'initrd' dynamic shell command to the build so we can load Linux initrds straight from the shell using the new generic protocol, which does not rely on initrd= being passed on the command line. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: reorganize TPM2 support in DSC/FDF filesArd Biesheuvel2020-01-091-0/+3
| | | | | | | | Put the TPM2 related DXE modules together in the DSC, and add a TPM2 support header comment while at it. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUEPeter Jones2019-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some tests check if it's defined or not. Additionally, in UefiPayloadPkg as well as some other trees, we define it as FALSE in the .dsc file. This patch changes all of the Ovmf platforms to explicitly define it as FALSE by default, and changes all of the checks to test if the value is TRUE. Signed-off-by: Peter Jones <pjones@redhat.com> Message-Id: <20190920184507.909884-1-pjones@redhat.com> [lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373] [lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] Cc: Andrew Fish <afish@apple.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: Don't build in QemuVideoDxe when we have CSMDavid Woodhouse2019-06-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | QemuVideoDxe installs its own legacy INT 10h handler for the benefit of systems like Windows 2008r2 which attempt to use INT 10h even when booted via EFI. This interacts extremely badly with a CSM actually attempting to install a real video BIOS. The last thing done before invoking a legacy OpROM is to call INT 10h to set a plain text mode. In the case where it's the video BIOS OpROM being loaded, INT 10h will normally point to an iret stub in the CSM itself. Unless QemuVideoDxe has changed INT10h to point to a location in the 0xC0000 segment that it didn't allocate properly, so the real OpROM has been shadowed over them top of it, and the INT 10h vector now points to some random place in the middle of the newly-shadowed OpROM. Don't Do That Then. QemuVideoDxe doesn't do any acceleration and just sets up a linear framebuffer, so we don't lose much by just unconditionally using BiosVideoDxe instead when CSM is present. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190626113742.819933-4-dwmw2@infradead.org>
* OvmfPkg: Update DSC/FDF files to consume CSM components in OvmfPkgHao A Wu2019-06-141-2/+2
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit updates the OVMF DSC/FDF files to consume the copied CSM components within OvmfPkg. Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Drop build flag USE_LEGACY_ISA_STACK and legacy ISA stackHao A Wu2019-06-111-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1842 According to the discussion at: https://edk2.groups.io/g/devel/topic/30918343#38093 For OVMF, we keep both ISA stacks: * The legacy one in PcAtChipsetPkg/IntelFrameworkModulePkg * The Sio bus based OVMF-specified one introduced by commit a5cc178aeb for a period of time (includes 1 stable tag: edk2-stable201905). And we also keep the Sio bus based OVMF-specified stack as the default one (via a build option 'USE_LEGACY_ISA_STACK') to validate its stability. This commit will propose to drop the legacy ISA stack from OVMF and remove the usage of the build flag 'USE_LEGACY_ISA_STACK' at the same time. This is considered as a preparation for the removal of PcAtChipsetPkg/IsaAcpiDxe & IntelFrameworkModulePkg. Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Update DSC/FDF to use NetworkPkg's include fragment file.Fu Siyuan2019-05-161-28/+1
| | | | | | | | | | | | | | | | | | | | | | | | This patch updates the platform DSC/FDF files to use the include fragment files provided by NetworkPkg. The feature enabling flags in [Defines] section have been updated to use the NetworkPkg's terms, and the value has been overridden with the original default value on this platform. v2:1.Make the comments before Network definition align other parts. 2.Set NETWORK_ALLOW_HTTP_CONNECTIONS true. 3.Remove TcpIoLib in lib classes section. 4.Withdraw the removal of [PcdsFixedAtBuild.X64]. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Message-Id: <20190516081810.27840-2-shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293 [lersek@redhat.com: add TianoCore Bugzilla reference]
* OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkgHao Wu2019-04-111-2/+2
| | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 This commit updates the OVMF DSC/FDF files to consume the copied 8259InterruptControllerDxe and 8254TimerDxe drivers within OvmfPkg. The unconsumed PCD: gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel is removed from DSC files as well. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-091-7/+1
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add a build flag to select ISA driver stackHao Wu2019-03-271-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495 This commit will add a static build flag 'USE_LEGACY_ISA_STACK' to select the ISA driver stack. If the flag is set to TRUE, the below driver stack will be used: PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf If the flag is set to FALSE, the below driver stack will be used: OvmfPkg/SioBusDxe/SioBusDxe.inf MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf The default value is set to FALSE in OVMF DSC files. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Ray Ni <ray.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Drop the ISA Floppy device supportHao Wu2019-03-271-2/+1
| | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495 There is a plan to remove the IntelFrameworkModulePkg: https://bugzilla.tianocore.org/show_bug.cgi?id=1605 And for driver: IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe This patch proposes to drop the ISA Floppy device support in OVMF. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Add TCG2 Configuration menu to the Device Manager menuStefan Berger2019-02-111-0/+3
| | | | | | | | | | | | | | | | | This patch adds the TCG2 Configuration menu to the Device Manager menu. We can apparently reuse the sample Tcg2ConfigDxe from SecurityPkg/Tcg/Tcg2Config without obvious adverse effects. The added TCG2 Configuration menu now shows details about the attached TPM 2.0 and lets one for example configure the active PCR banks or issue commands, among other things. The code is added to Ovmf by building with -DTPM2_ENABLE and -DTPM2_CONFIG_ENABLE. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chainLiming Gao2018-11-271-0/+2
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1355 XCODE doesn't support HII resource section. TftpDynamicCommand driver depends on HII resource section. To let OvmfPkg boot to shell on XCODE5 tool chain, don't include TftpDynamicCommand driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Remove EdkShellBinPkg in FDFshenglei2018-11-191-4/+0
| | | | | | | | | | | | | | | | Remove EdkShellBinPkg in OvmfPkgIa32.fdf, OvmfPkg/OvmfPkgIa32X64.fdf amd OvmfPkg/OvmfPkgX64.fdf. https://bugzilla.tianocore.org/show_bug.cgi?id=1108 v2: Remove USE_OLD_SHELL in DSC and FDF because it will be unnecessary to use it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace obsoleted network drivers from platform DSC/FDF.Fu Siyuan2018-11-061-7/+3
| | | | | | | | | | | | | | | | | | V2: Add missed library instance for NetworkPkg iSCSI driver. This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively maintained and will be removed from edk2 master soon. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add QemuRamfbDxeGerd Hoffmann2018-06-141-0/+1
| | | | | | | | | | | Add a driver for the qemu ramfb display device. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> [lersek@redhat.com: fix INF banner typo] [lersek@redhat.com: make some local variable definitions more idiomatic] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: raise DXEFV size to 11 MBLaszlo Ersek2018-05-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost exactly two years after commit 2f7b34b20842f, we've grown out the 10MB DXEFV: > build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ > -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E1000_ENABLE \ > -D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE > > [...] > > GenFv: ERROR 3000: Invalid > the required fv image size 0xa28d48 exceeds the set fv image size > 0xa00000 Raise the DXEFV size to 11MB. (For builds that don't need this DXEFV bump, I've checked the FVMAIN_COMPACT increase stemming from the additional 1MB padding, using NOOPT + GCC48 + FD_SIZE_2MB, and no other "-D" flags. In the IA32 build, FVMAIN_COMPACT grows by 232 bytes. In the IA32X64 build, FVMAIN_COMPACT shrinks by 64 bytes. In the X64 build, FVMAIN_COMPACT shrinks by 376 bytes.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxeLaszlo Ersek2018-04-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. In the past eight years, no driver or application seems to have materialized that produced BLOCK_MMIO_PROTOCOL instances. Meanwhile the UEFI spec has developed the EFI_RAM_DISK_PROTOCOL, which edk2 implements (and OVMF includes) as RamDiskDxe. Rather than fixing issues in the unused BlockMmioToBlockIoDxe driver, remove the driver, together with the BLOCK_MMIO_PROTOCOL definition that now becomes unused too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=926 Reported-by: Steven Shi <steven.shi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: include Tcg2Dxe moduleMarc-André Lureau2018-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This module measures and log the boot environment. It also produces the Tcg2 protocol, which allows for example to read the log from OS. The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2, which is required for crypto-agile log. In fact, only upcoming 4.16 adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2: [ 0.000000] efi: EFI v2.70 by EDK II [ 0.000000] efi: SMBIOS=0x3fa1f000 ACPI=0x3fbb6000 ACPI 2.0=0x3fbb6014 MEMATTR=0x3e7d4318 TPMEventLog=0x3db21018 $ python chipsec_util.py tpm parse_log binary_bios_measurements [CHIPSEC] Version 1.3.5.dev2 [CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module) [CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements'] PCR: 0 type: EV_S_CRTM_VERSION size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29 + version: PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc + base: 0x820000 length: 0xe0000 PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c + base: 0x900000 length: 0xa00000 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e PCR: 7 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c PCR: 4 type: EV_EFI_ACTION size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256 PCR: 0 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 1 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 2 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 3 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 4 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 5 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 $ tpm2_pcrlist sha1 : 0 : 35bd1786b6909daad610d7598b1d620352d33b8a 1 : ec0511e860206e0af13c31da2f9e943fb6ca353d 2 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 3 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 4 : 45a323382bd933f08e7f0e256bc8249e4095b1ec 5 : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b 6 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 7 : 518bd167271fbb64589c61e43d8c0165861431d8 8 : 0000000000000000000000000000000000000000 9 : 0000000000000000000000000000000000000000 10 : 0000000000000000000000000000000000000000 11 : 0000000000000000000000000000000000000000 12 : 0000000000000000000000000000000000000000 13 : 0000000000000000000000000000000000000000 14 : 0000000000000000000000000000000000000000 15 : 0000000000000000000000000000000000000000 16 : 0000000000000000000000000000000000000000 17 : ffffffffffffffffffffffffffffffffffffffff 18 : ffffffffffffffffffffffffffffffffffffffff 19 : ffffffffffffffffffffffffffffffffffffffff 20 : ffffffffffffffffffffffffffffffffffffffff 21 : ffffffffffffffffffffffffffffffffffffffff 22 : ffffffffffffffffffffffffffffffffffffffff 23 : 0000000000000000000000000000000000000000 sha256 : 0 : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c 1 : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8 2 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 3 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 4 : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35 5 : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0 6 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 7 : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068 8 : 0000000000000000000000000000000000000000000000000000000000000000 9 : 0000000000000000000000000000000000000000000000000000000000000000 10 : 0000000000000000000000000000000000000000000000000000000000000000 11 : 0000000000000000000000000000000000000000000000000000000000000000 12 : 0000000000000000000000000000000000000000000000000000000000000000 13 : 0000000000000000000000000000000000000000000000000000000000000000 14 : 0000000000000000000000000000000000000000000000000000000000000000 15 : 0000000000000000000000000000000000000000000000000000000000000000 16 : 0000000000000000000000000000000000000000000000000000000000000000 17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 23 : 0000000000000000000000000000000000000000000000000000000000000000 sha384 : The PhysicalPresenceLib is required, it sets some variables, but the firmware doesn't act on it yet. Laszlo Ersek explained on the list why Tpm2DeviceLib has to be resolved differently for DXE_DRIVER modules in general and for "Tcg2Dxe.inf" specifically: * We have a library class called Tpm2DeviceLib -- this is basically the set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h". Its leading comment says "This library abstract how to access TPM2 hardware device". There are two *sets* of APIs in "Tpm2DeviceLib.h": (a) functions that deal with the TPM2 device: - Tpm2RequestUseTpm(), - Tpm2SubmitCommand() This set of APIs is supposed to be used by clients that *consume* the TPM2 device abstraction. (b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be used by *providers* of various TPM2 device abstractions. * Then, we have two implementations (instances) of the Tpm2DeviceLib class: (1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf (2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf (1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the APIs listed under (a), and it does not implement (b) -- see EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for drivers that *consume* the TPM2 device abstraction. And, the (a) group of APIs is implemented by forwarding the requests to the TCG2 protocol. The idea here is that all the drivers that consume the TPM2 abstraction do not have to be statically linked with a large TPM2 device library instance; instead they are only linked (statically) with this "thin" library instance, and all the actual work is delegated to whichever driver that provides the singleton TCG2 protocol. (2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant for the driver that offers (produces) the TCG2 protocol. This lib instance implements both (a) and (b) API groups. * Here's how things fit together: (i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf" library instance (which has no lib class) is linked into "Tcg2Dxe.inf" via NULL class resolution. This simply means that before the "Tcg2Dxe.inf" entry point function is entered, the constructor function of "Tpm2InstanceLibDTpm.inf" will be called. (ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and registers its own actual TPM2 command implementation with the "Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe driver). This provides the back-end for the API set (a). TCG2 protocol provider (Tcg2Dxe.inf driver) launches | v NULL class: Tpm2InstanceLibDTpm instance construction | v Tpm2DeviceLib class: Tpm2DeviceLibRouter instance backend registration for API set (a) (iii) The Tcg2Dxe driver exposes the TCG2 protocol. (iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls land in Tcg2Dxe, via the protocol. (v) Tcg2Dxe serves the protocol request by forwarding it to API set (a) from lib instance (2). (vi) Those functions call the "backend" functions registered by Tpm2DeviceLibDTpm in step (ii). TPM 2 consumer driver | v Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance | v TCG2 protocol interface | v TCG2 protocol provider: Tcg2Dxe.inf driver | v Tpm2DeviceLib class: Tpm2DeviceLibRouter instance | v NULL class: Tpm2InstanceLibDTpm instance (via earlier registration) | v TPM2 chip (actual hardware) * So that is the "router" pattern in edk2. Namely, - Consumers of an abstraction use a thin library instance. - The thin library instance calls a firmware-global (singleton) service, i.e. a PPI (in the PEI phase) or protocol (in the DXE phase). - The PEIM providing the PPI, or the DXE driver providing the protocol, don't themselves implement the actual service either. Instead they offer a "registration" service too, and they only connect the incoming "consumer" calls to the earlier registered back-end(s). - The "registration service", for back-ends to use, may take various forms. It can be exposed globally to the rest of the firmware, as another member function of the PPI / protocol structure. Then backends can be provided by separate PEIMs / DXE drivers. Or else, the registration service can be exposed as just another library API. In this case, the backends are provided as NULL class library instances, and a platform DSC file links them into the PEIM / DXE driver via NULL class resolutions. The backend lib instances call the registration service in their own respective constructor functions. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include Tcg2Pei moduleMarc-André Lureau2018-03-091-0/+1
| | | | | | | | | | | | | This module will initialize TPM device, measure reported FVs and BIOS version. We keep both SHA-1 and SHA-256 for the TCG 1.2 log format compatibility, but the SHA-256 measurements and TCG 2 log format are now recommended. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add customized Tcg2ConfigPei cloneMarc-André Lureau2018-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Tcg2ConfigPei module informs the firmware globally about the TPM device type, by setting the PcdTpmInstanceGuid PCD to the appropriate GUID value. The original module under SecurityPkg can perform device detection, or read a cached value from a non-volatile UEFI variable. OvmfPkg's clone of the module only performs the TPM2 hardware detection. This is what the module does: - Check the QEMU hardware for TPM2 availability only - If found, set the dynamic PCD "PcdTpmInstanceGuid" to &gEfiTpmDeviceInstanceTpm20DtpmGuid. This is what informs the rest of the firmware about the TPM type. - Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD. In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting and the consumption of the "TPM type" PCD. - If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid. (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if no TPM2 is available. So in that case our Tcg2ConfigPei must do it.) Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add tftp dynamic commandRuiyu Ni2017-11-291-1/+2
| | | | | | | | | | | | | | | The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. This patch complements commit f9bc2f876326, which only removed the old library, but didn't add the new dynamic command。 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org>
* OvmfPkg: restore temporary SEC/PEI RAM size to 64KBLaszlo Ersek2017-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) In the PEI phase, the PCD database is maintained in a GUID HOB. In OVMF, we load the PCD PEIM before any other PEIMs (using APRIORI PEI), so that all other PEIMs can use dynamic PCDs. Consequently, - the PCD GUID HOB is initially allocated from the temporary SEC/PEI heap, - whenever we introduce a dynamic PCD to a PEIM built into OVMF such that the PCD is new to OVMF's whole PEI phase, the PCD GUID HOB (and its temporary heap footprint) grow. I've noticed that, if we add just one more dynamic PCD to the PEI phase, then in the X64 build, - we get very close to the half of the temporary heap (i.e., 8192 bytes), - obscure PEI phase hangs or DXE core initialization failures (ASSERTs) occur. The symptoms vary between the FD_SIZE_2MB and FD_SIZE_4MB builds of X64 OVMF. (2) I've found that commit 2bbd7e2fbd4b ("UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings", 2017-09-27) introduced a large (16KB) stack allocation: > The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and > MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation. > ... > +#define SCRATCH_BUFFER_SIZE (4 * SIZE_4KB) > ... > @@ -2207,17 +2462,66 @@ MtrrSetMemoryAttributeInMtrrSettings ( > ... > + UINT8 Scratch[SCRATCH_BUFFER_SIZE]; (3) OVMF's temp SEC/PEI RAM size has been 32KB ever since commit 7cb6b0e06809 ("OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000", 2014-01-21) Of that, the upper 16KB half is stack (growing down), and the lower 16KB half is heap. Thus, OvmfPkg/PlatformPei's calls to "UefiCpuPkg/Library/MtrrLib", in QemuInitializeRam(), cause the Scratch array to overflow the entire stack (heading towards lower addresses), and corrupt the heap below the stack. It turns out that the total stack demand is about 24KB, so the overflow is able to corrupt the upper 8KB of the heap. If that part of the heap is actually used (for example because we grow the PCD GUID HOB sufficiently), mayhem ensues. (4) Right after commit 7cb6b0e06809 (see above), there would be no room left above the 32KB temp SEC/PEI RAM. However, given more recent commits 45d870815156 ("OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3", 2016-07-13) 6b04cca4d697 ("OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySize", 2016-07-12) we can now restore the temp SEC/PEI RAM size to the original (pre-7cb6b0e06809) 64KB. This will allow for a 32KB temp SEC/PEI stack, which accommodates the ~24KB demand mentioned in (3). (Prior patches in this series will let us monitor the stack usage in the future.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747 Ref: http://mid.mail-archive.com/a49cc089-12ae-a887-a4d6-4dc509233a74@redhat.com Ref: http://mid.mail-archive.com/03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Enable UDF file system supportPaulo Alcantara2017-09-081-0/+1
| | | | | | | | | | | This patch enables UDF file system support by default. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* OvmfPkg: Add IoMmuDxe driverBrijesh Singh2017-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IOMMU protocol driver provides capabilities to set a DMA access attribute and methods to allocate, free, map and unmap the DMA memory for the PCI Bus devices. Due to security reasons all DMA operations inside the SEV guest must be performed on shared (i.e unencrypted) pages. The IOMMU protocol driver for the SEV guest uses a bounce buffer to map guest DMA buffer to shared pages inorder to provide the support for DMA operations inside SEV guest. IoMmuDxe driver looks for SEV capabilities, if present then it installs the real IOMMU protocol otherwise it installs placeholder protocol. Currently, PciHostBridgeDxe and QemuFWCfgLib need to know the existance of IOMMU protocol. The modules needing to know the existance of IOMMU support should add gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid in their depex to ensure that platform IOMMU detection has been performed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil v.22Laszlo Ersek2017-07-051-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Jiaxin reports that the OvmfPkg/README instructions for downloading the Intel PROEFI drivers, and the filenames in OvmfPkg/OvmfPkg*.fdf for incorporating the same in the OVMF binaries, are no longer up to date; the download link has stopped working. Additionally, the IA32 driver binary is no more distributed by Intel. Update OvmfPkg/README with new download instructions, and adapt the OVMF FDF files. With this driver in use for QEMU's e1000 NIC, the DH shell command prints, as Controller Name, "Intel(R) PRO/1000 MT Network Connection". I successfully tested DHCP and ping from the UEFI shell. Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reported-by: Jiaxin Wu <jiaxin.wu@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: disable build-time relocation for DXEFV modulesLaszlo Ersek2017-07-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the GenFv utility from BaseTools composes a firmware volume, it checks whether modules in the firmware volume are subject to build-time relocation. The primary indication for relocation is whether the firmware volume has a nonzero base address, according to the [FD] section(s) in the FDF file that refer to the firmware volume. The idea behind build-time relocation is that XIP (execute in place) modules will not be relocated at boot-time: - Pre-DXE phase modules generally execute in place. (OVMF is no exception, despite the fact that we have writeable memory even in SEC: PEI_CORE and PEIMs run in-place from PEIFV, after SEC decompresses PEIFV and DXEFV from FVMAIN_COMPACT (flash) to RAM. PEI_CORE and the PEIMs are relocated at boot-time only after PlatformPei installs the permanent PEI RAM, and the RAM migration occurs.) - Modules dispatched by the DXE Core are generally relocated at boot-time. However, this is not necessarily so. Quoting Liming from <https://lists.01.org/pipermail/edk2-devel/2017-July/012053.html>: > PI spec has no limitation that XIP is for PEIM only. DXE driver may be > built as XIP for other purpose. For example, if DXE driver image address > is not zero, DxeCore will try allocating the preferred address and load > it. In another case, once DXE driver is relocated at build time, DxeCore > will dispatch it and start it directly without loading, it may save boot > performance. Therefore GenFv relocates even DXE and UEFI driver modules if the containing firmware volume has a nonzero base address. In OVMF, this is the case for both PEIV and DXEFV: > [FD.MEMFD] > BaseAddress = $(MEMFD_BASE_ADDRESS) > Size = 0xB00000 > ErasePolarity = 1 > BlockSize = 0x10000 > NumBlocks = 0xB0 > ... > 0x020000|0x0E0000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize > FV = PEIFV > > 0x100000|0xA00000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize > FV = DXEFV While the build-time relocation certainly makes sense for PEIFV (see above), the reasons for which we specify DXEFV under [FD.MEMFD] are weaker: - we set the PcdOvmfDxeMemFvBase and PcdOvmfDxeMemFvSize PCDs here, - and we ascertain that DXEFV, when decompressed by SEC from FVMAIN_COMPACT, will fit into the area allotted here, at build time. In other words, the build-time relocation of the modules in DXEFV is a waste of resources. But, it gets worse: Build-time relocation of an executable is only possible if the on-disk and in-memory layouts are identical, i.e., if the sections of the PE/COFF image adhere to the same alignment on disk and in memory. Put differently, the FileAlignment and SectionAlignment headers must be equal. For boot-time modules that we build as part of edk2, both alignment values are 0x20 bytes. For runtime modules that we build as part of edk2, both alignment values are 0x1000 bytes. This is why the DXEFV relocation, albeit wasteful, is also successful every time. Unfortunately, if we try to include a PE/COFF binary in DXEFV that originates from outside of edk2, the DXEFV relocation can fail due to the binary having unmatched FileAlignment and SectionAlignment headers. This is precisely the case with the E3522X2.EFI network driver for the e1000 NIC, from Intel's BootUtil / PREBOOT.EXE distribution. The solution is to use the FvForceRebase=FALSE override under [FV.DXEFV]. This tells GenFv not to perform build-time relocation on the firmware volume, despite the FV having a nonzero base address. In DXEFV we also have SMM drivers. Those are relocated at boot-time (into SMRAM) unconditionally; SMRAM is always discovered at boot-time. Kudos to Ard and Liming for the PE/COFF sections & relocations explanation, and for the FvForceRebase=FALSE tip. I regression-tested this change in the following configurations (all with normal boot and S3 suspend/resume): IA32, q35, SMM, Linux IA32X64, q35, SMM, Linux IA32X64, q35, SMM, Windows-8.1 X64, i440fx, no-SMM, Linux Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Liming Gao <liming.gao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=615 Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: pull in TLS modules with -D TLS_ENABLE (also enabling HTTPS)Gary Lin2017-01-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | This commit introduces a new build option, TLS_ENABLE, to pull in the TLS-related modules. If HTTP_BOOT_ENABLE and TLS_ENABLE are enabled at the same time, the HTTP driver locates the TLS protocols automatically and thus HTTPS is enabled. To build OVMF with HTTP Boot: $ ./build.sh -D HTTP_BOOT_ENABLE To build OVMF with HTTPS Boot: $ ./build.sh -D HTTP_BOOT_ENABLE -D TLS_ENABLE Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: correct the IScsiDxe module included for the IPv6 stackGary Lin2017-01-171-4/+0
| | | | | | | | | | | | | | | | | | | | | Always use IScsiDxe from NetworkPkg when IPv6 is enabled since it provides the complete ISCSI support. NOTE: This makes OpenSSL a hard requirement when NETWORK_IP6_ENABLE is true. (Based on Jiaxin's suggestion) Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Install BGRT ACPI tableBhupesh Sharma2017-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While debugging OS for ACPI BGRT support (especially on VMs), it is very useful to have the EFI firmware (OVMF in most cases which use Tianocore) to export the ACPI BGRT table. This patch tries to add this support in OvmfPkg. Tested this patch in the following environments: 1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host: - Ensured that the BGRT logo is properly prepared and can be viewed with user-space tools (like 'Gwenview' on KDE, for example): $ file /sys/firmware/acpi/bgrt/image /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x 58 x 24 2. On a Windows-10 VM Guest running on a Fedora-24 Host: - Ensured that the BGRT ACPI table is properly prepared and can be read with freeware tool like FirmwareTablesView: ================================================== Signature : BGRT Firmware Provider : ACPI Length : 56 Revision : 1 Checksum : 129 OEM ID : INTEL OEM Table ID : EDK2 OEM Revision : 0x00000002 Creator ID : 0x20202020 Creator Revision : 0x01000013 Description : ================================================== Note from Laszlo Ersek <lersek@redhat.com>: without the BGRT ACPI table, Windows 8 and Windows 10 first clear the screen, then display a blue, slanted Windows picture above the rotating white boot animation. With the BGRT ACPI table, Windows 8 and Windows 10 don't clear the screen, the blue Windows image is not displayed, and the rotating white boot animation is shown between the firmware's original TianoCore boot splash and (optional) "Start boot option" progress bar. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: cover effect on Windows 8/10 boot anim. in commit msg] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use the new LogoDxe driverRuiyu Ni2016-09-281-3/+1
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
* OvmfPkg: Use MdeModulePkg/ResetSystemRuntimeDxeRuiyu Ni2016-09-021-1/+1
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF filesLaszlo Ersek2016-09-011-0/+1
| | | | | | | | | | | | At this stage, the driver builds, and suffices for testing binding and unbinding. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: use StatusCode Router and Handler from MdeModulePkgCinnamon Shia2016-08-021-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the Platform Init v1.4a spec, - Volume 1 "4.7 Status Code Service" defines the EFI_PEI_SERVICES.ReportStatusCode() service, - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), - Volume 2 "14.2 Status Code Runtime Protocol" defines the EFI_STATUS_CODE_PROTOCOL. These allow PEIMs and DXE (and later) modules to report status codes. Currently OvmfPkg uses modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above abstractions (PPI and PROTOCOL) directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. In the Platform Init v1.4a spec, - Volume 3 "7.2.2 Report Status Code Handler PPI" defines EFI_PEI_RSC_HANDLER_PPI, - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines EFI_RSC_HANDLER_PROTOCOL. These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com> Suggested-by: Liming Gao <liming.gao@intel.com> Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63 [jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include UefiCpuPkg/CpuMpPeiLaszlo Ersek2016-07-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use. CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those already used by CpuDxe: - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these control whether CpuMpPei performs microcode update. If the region size is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the region size to zero by default, which is appropriate for OVMF. - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait (with PAUSE). The latter PCD is only relevant if the former PCD is 2 (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself, we choose HLT. That's the default set by UefiCpuPkg.dec. Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib technically, it is supposed to consume PeiCpuExceptionHandlerLib. See: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703 - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module"), part of the series linked above. Jeff recommended to resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all PEIMs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477 Since at the moment we have no resolution in place that would cover this for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]), it's easy to do. Cc: Jeff Fan <jeff.fan@intel.com> 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: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySizeLaszlo Ersek2016-07-151-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | No module in OvmfPkg uses these PCDs any longer. The first PCD mentioned is declared by OvmfPkg, so we can remove even the declaration. The second PCD comes from IntelFrameworkModulePkg. The module that consumes PcdS3AcpiReservedMemorySize is called "IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe", and it is built into OVMF. However, AcpiS3SaveDxe consumes the PCD only conditionally: it depends on the feature PCD called PcdFrameworkCompatibilitySupport, which we never enable in OVMF. The 32KB gap that used to be the S3 permanent PEI memory is left unused in MEMFD for now; it never hurts to have a few KB available there, for future features. Cc: Jeff Fan <jeff.fan@intel.com> 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: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: add PciHotPlugInitDxeLaszlo Ersek2016-07-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After IncompatiblePciDeviceSupportDxe, this is another small driver / protocol implementation that tweaks the behavior of the PCI bus driver in edk2. The protocol is specified in the Platform Init Spec v1.4a, Volume 5, Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This implementation steers the PCI bus driver to reserve the following resources ("padding") for each PCI bus, in addition to the BARs of the devices on that PCI bus: - 2MB of 64-bit non-prefetchable MMIO aperture, - 512B of IO port space. The goal is to reserve room for devices hot-plugged at runtime even if the bridge receiving the device is empty at boot time. The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is actually only 1/8th of the PCI spec mandated reservation, but the specified size of 4096 has proved wasteful (given the limited size of our IO port space -- see commit bba734ab4c7c). Especially on Q35, where every PCIe root port and downstream port qualifies as a separate bridge (capable of accepting a single device). Test results for this patch: - regardless of our request for 64-bit MMIO reservation, it is downgraded to 32-bit, - although we request 512B alignment for the IO port space reservation, the next upstream bridge rounds it up to 4096B. Cc: "Johnson, Brian J." <bjohnson@sgi.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
* OvmfPkg: add a Name GUID to each Firmware VolumeLaszlo Ersek2016-07-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but the detailed description can be found in Volume 3 of the Platform Init spec (which is at 1.4a currently). Adding an FvNameGuid statement to [FV.xxx] has the following effects (implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"): - The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not directly, see below). - An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to address. This object is not followed by any EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only specifies the Name GUID for the firmware volume. The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found in the Build directory as a separate file (20 bytes in size): Build/Ovmf*/*_GCC*/FV/*.ext - The new data consume 48 bytes in the following volumes: SECFV, FVMAIN_COMPACT, DXEFV. They comprise: - 16 padding bytes, - EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize fields, and Type=EFI_FV_FILETYPE_FFS_PAD), - EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above), - 4 padding bytes. (The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point immediately past EFI_FIRMWARE_VOLUME_HEADER.) The sizes of the firmware volumes don't change, only their internal usages grow by 48 bytes. I verified that the statements and calculations in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid. - The new data consume 0 bytes in PEIFV. This is because PEIFV has enough internal padding at the moment to accomodate the above structures without a growth in usage. In the future, firmware volumes can be identified by Name GUID (Fv(...) device path nodes), rather than memory location (MemoryMapped(...) device path nodes). This is supposed to improve stability for persistent device paths that refer to FFS files; for example, UEFI boot options. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Suggested-by: Ruiyu Ni <ruiyu.ni@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>
* OvmfPkg: Re-add the Driver Health ManagerBruce Cran2016-06-281-0/+1
| | | | | | | | | | | | | | | The Driver Health HII menu is not an integral part of the MdeModulePkg BDS driver / UI app. Because we abandoned the IntelFrameworkModulePkg BDS, now we have to get the same functionality explicitly from DriverHealthManagerDxe. Suggested-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 18:29:08 +0000