summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkg.dec
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: define CPU_HOT_EJECT_DATAAnkur Arora2021-03-161-0/+4
| | | | | | | | | | | | | | | | | Define CPU_HOT_EJECT_DATA and add PCD PcdCpuHotEjectDataAddress, which will be used to share CPU ejection state between OvmfPkg/CpuHotPlugSmm and PiSmmCpuDxeSmm. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Aaron Young <aaron.young@oracle.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Message-Id: <20210312062656.2477515-6-ankur.a.arora@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Introduce PciHostBridgeUtilityLib classJiahui Cen via groups.io2021-01-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | Introduce a new PciHostBridgeUtilityLib class to share duplicate code between OvmfPkg and ArmVirtPkg. Extract function PciHostBridgeUtilityResourceConflict from PciHostBridgeResourceConflict in OvmfPkg/PciHostBridgeLib. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210119011302.10908-2-cenjiahui@huawei.com>
* OvmfPkg/VmgExitLib: Support nested #VCsTom Lendacky2021-01-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In order to be able to issue messages or make interface calls that cause another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support for nested #VCs. In order to support nested #VCs, GHCB backup pages are required. If a #VC is received while currently processing a #VC, a backup of the current GHCB content is made. This allows the #VC handler to continue processing the new #VC. Upon completion of the new #VC, the GHCB is restored from the backup page. The #VC recursion level is tracked in the per-vCPU variable area. Support is added to handle up to one nested #VC (or two #VCs total). If a second nested #VC is encountered, an ASSERT will be issued and the vCPU will enter CpuDeadLoop (). For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory layout, with two new fixed PCDs to provide the address and size of the backup area. For PEI/DXE, the GHCB backup pages are allocated as boot services pages using the memory allocation library. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/AmdSev/SecretDxe: make secret location naming genericJames Bottomley2020-12-181-1/+1
| | | | | | | | | | | | It is anticipated that this part of the code will work for both Intel TDX and AMD SEV, so remove the SEV specific naming and change to ConfidentialComputing as a more architecture neutral prefix. Apart from the symbol rename, there are no code changes. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Message-Id: <20201216014146.2229-3-jejb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration tableJames Bottomley2020-12-141-0/+1
| | | | | | | | | | | | | | Now that the secret area is protected by a boot time HOB, extract its location details into a configuration table referenced by gSevLaunchSecretGuid so the boot loader or OS can locate it before a call to ExitBootServices(). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-7-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix indentation of InstallConfigurationTable() args]
* OvmfPkg: create a SEV secret area in the AmdSev memfdJames Bottomley2020-12-141-0/+6
| | | | | | | | | | | | | | SEV needs an area to place an injected secret where OVMF can find it and pass it up as a ConfigurationTable. This patch implements the area itself as an addition to the SEV enhanced reset vector table using an additional guid (4c2eb361-7d9b-4cc3-8081-127c90d3d294). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-5-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix typo in "ResetVectorVtf0.asm" comments]
* OvmfPkg/AmdSev: add Grub Firmware Volume PackageJames Bottomley2020-12-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used to package up the grub bootloader into a firmware volume where it can be executed as a shell like the UEFI Shell. Grub itself is built as a minimal entity into a Fv and then added as a boot option. By default the UEFI shell isn't built but for debugging purposes it can be enabled and will then be presented as a boot option (This should never be allowed for secure boot in an external data centre but may be useful for local debugging). Finally all other boot options except grub and possibly the shell are stripped and the boot timeout forced to 0 so the system will not enter a setup menu and will only boot to grub. This is done by copying the Library/PlatformBootManagerLib into Library/PlatformBootManagerLibGrub and then customizing it. Boot failure is fatal to try to prevent secret theft. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-4-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: replace local variable initialization with assignment] Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: squash 'OvmfPkg: add "gGrubFileGuid=Grub" to GuidCheck.IgnoreDuplicates', reviewed stand-alone by Phil (msgid <e6eae551-8563-ccfb-5547-7a97da6d46e5@redhat.com>) and Ard (msgid <10aeda37-def6-d9a4-6e02-4c66c1492f57@arm.com>)]
* OvmfPkg: Create a GHCB page for use during Sec phaseTom Lendacky2020-08-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A GHCB page is needed during the Sec phase, so this new page must be created. Since the #VC exception handler routines assume that a per-CPU variable area is immediately after the GHCB, this per-CPU variable area must also be created. Since the GHCB must be marked as an un-encrypted, or shared, page, an additional pagetable page is required to break down the 2MB region where the GHCB page lives into 4K pagetable entries. Create a new entry in the OVMF memory layout for the new page table page and for the SEC GHCB and per-CPU variable pages. After breaking down the 2MB page, update the GHCB page table entry to remove the encryption mask. The GHCB page will be used by the SEC #VC exception handler. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB in order to perform the requested function. Four new fixed PCDs are needed to support the SEC GHCB page: - PcdOvmfSecGhcbBase UINT32 value that is the base address of the GHCB used during the SEC phase. - PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the GHCB area used during the SEC phase. - PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page table page used to break down the 2MB page into 512 4K pages. - PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes, of the page table page. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: fix DEC spec violation introduced by Bhyve additionLaszlo Ersek2020-08-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sean reports that having two DEC files under OvmfPkg violates the DEC spec: > An EDK II Package (directory) is a directory that contains an EDK II > package declaration (DEC) file. Only one DEC file is permitted per > directory. EDK II Packages cannot be nested within other EDK II > Packages. This issue originates from commit 656419f922c0 ("Add BhyvePkg, to support the bhyve hypervisor", 2020-07-31). Remedy the problem as follows. (Note that these steps are not split to multiple patches in order to keep Bhyve buildable across the transition.) (1) Delete "OvmfPkg/Bhyve/BhyvePkg.dec". (2) Point the [Packages] sections of the Bhyve-specific AcpiPlatformDxe, BhyveRfbDxe, and BhyveFwCtlLib INF files to "OvmfPkg.dec". (3) Migrate the artifacts that "BhyvePkg.dec" used to have on top of "OvmfPkg.dec" as follows: (3a) Merge the copyright notices from Rebecca Cran and Pluribus Networks into "OvmfPkg.dec". (3b) Merge the "BhyveFwCtlLib" class header definition into "OvmfPkg.dec". (3c) Merge value 0x2F8 for the fixed PcdDebugIoPort into "BhyvePkgX64.dsc". (4) Unnest the the Include/Library/ and Library/ subtrees from under OvmfPkg/Bhyve to the corresponding, preexistent subtrees in OvmfPkg. The goal is to keep the [Includes] section in the "OvmfPkg.dec" file unchanged, plus simplify references in "BhyvePkgX64.dsc". Non-library modules remain under "OvmfPkg/Bhyve/". (4a) The BhyveFwCtlLib class header, and sole instance, are already uniquely named, so their movements need not involve file renames. (4b) Rename the Bhyve-specific PlatformBootManagerLib instance to PlatformBootManagerLibBhyve, in additon to moving it, for distinguishing it from OvmfPkg's preexistent lib instance. Apply the name change to all three of the lib instance directory name, the INF file, and the BASE_NAME define in the INF file. (4c) Update lib class resolutions in "BhyvePkgX64.dsc" accordingly. (5) Replace the "ACPI table storage" FILE_GUID in "OvmfPkg/Bhyve/AcpiTables/AcpiTables.inf" with a new GUID, and open-code the "ACPI table storage" GUID in the "ACPITABLE" FDF rule instead, replacing $(NAMED_GUID). This step is necessary because CI requires unique FILE_GUIDs over all INF files, and OVMF's original "AcpiTables.inf" already uses the "ACPI table storage" GUID as FILE_GUID. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sean Brogan <spbrogan@outlook.com> Fixes: 656419f922c047a3c48bd3f4ecea7d8e87d0b761 Reported-by: Sean Brogan <spbrogan@outlook.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200801155024.16439-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/LsiScsiDxe: Process the SCSI Request PacketGary Lin2020-07-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of LsiScsiPassThru(). LsiScsiProcessRequest() is added to translate the SCSI Request Packet into the LSI 53C895A commands. This function utilizes the so-called Script buffer to transmit a series of commands to the chip and then polls the DMA Status (DSTAT) register until the Scripts Interrupt Instruction Received (SIR) bit sets. Once the script is done, the SCSI Request Packet will be modified to reflect the result of the script. The Cumulative SCSI Byte Count (CSBC) register is fetched before and after the script to calculate the transferred bytes and update InTransferLength/OutTransferLength if necessary. v3: - Set DStat, SIst0, and SIst1 to 0 before using them - Amend the if statements for the DMA data instruction and add the assertions for the data direction - Also set SenseDataLength to 0 on the error path - Fix typos and amend comments - Amend the error handling of the calculation of transferred bytes v2: - Use the BITx macros for the most of LSI_* constants - Fix a typo: contorller => controller - Add SeaBIOS lsi-scsi driver as one of the references of the script - Cast the result of sizeof to UINT32 for the instructions of the script - Drop the backslashes - Replace LSI_SCSI_DMA_ADDR_LOW with LSI_SCSI_DMA_ADDR since we already removed DUAL_ADDRESS_CYCLE - Add more comments for the script - Fix the check of the script size at the end of the script - Always set SenseDataLength to 0 to avoid the caller to access SenseData - Improve the error handling in LsiScsiProcessRequest() Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Gary Lin <glin@suse.com> Message-Id: <20200717061130.8881-11-glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/LsiScsiDxe: Report Targets and LUNsGary Lin2020-07-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Implement LsiScsiGetNextTargetLun(), LsiScsiBuildDevicePath(), LsiScsiGetTargetLun(), and LsiScsiGetNextTarget() to report Targets and LUNs and build the device path. This commit also introduces two PCD value: PcdLsiScsiMaxTargetLimit and PcdLsiScsiMaxLunLimit as the limits for Targets and LUNs. v3: - Update the range of LUN in the assertioin - Squash the spurious newline into the previous commit v2: - Zero out (*Target) in LsiScsiGetTargetLun() - Use CopyMem() instead of the one-byte shortcut to copy target from ScsiDevicePath->Pun - Add asserts for PcdLsiScsiMaxTargetLimit and PcdLsiScsiMaxLunLimit Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Gary Lin <glin@suse.com> Message-Id: <20200717061130.8881-7-glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkg.dec: Adjust PcdMptScsiStallPerPollUsec token valueGary Lin2020-07-151-1/+1
| | | | | | | | | | | | | | | | The token value of PcdMptScsiStallPerPollUsec should be 0x3a since the previous token value is 0x39. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Liran Alon <liran.alon@oracle.com> Cc: Nikita Leshenko <nikita.leshchenko@oracle.com> Signed-off-by: Gary Lin <glin@suse.com> Message-Id: <20200715082031.30978-1-glin@suse.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> [lersek@redhat.com: clarify subject, fix typos in commit message] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/MptScsiDxe: Implement the PassThru methodNikita Leshenko2020-05-051-0/+3
| | | | | | | | | | | | Machines should be able to boot after this commit. Tested with different Linux distributions (Ubuntu, CentOS) and different Windows versions (Windows 7, Windows 10, Server 2016). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-12-nikita.leshchenko@oracle.com> [lersek@redhat.com: MPT_SCSI_DMA_ADDR_HIGH: drop redundant space char]
* OvmfPkg/MptScsiDxe: Report targets and one LUNNikita Leshenko2020-05-051-0/+4
| | | | | | | | | | | | | | | The controller supports up to 8 targets in practice (Not reported by the controller, but based on the implementation of the virtual device), report them in GetNextTarget and GetNextTargetLun. The firmware will then try to communicate with them and create a block device for each one that responds. Support for multiple LUNs will be implemented in another series. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-7-nikita.leshchenko@oracle.com>
* OvmfPkg: introduce QemuFwCfgSimpleParserLibLaszlo Ersek2020-04-281-0/+4
| | | | | | | | | | | | | | | | We already parse some boolean and integer values from named fw_cfg files (usually into PCDs), and we're going to cover more. Add a dedicated library for centralizing the parsing logic. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: supply missing lib class declarations in the DEC fileLaszlo Ersek2020-04-081-0/+14
| | | | | | | | | | | | | | | | | | | | | | | List the header files in the OvmfPkg DEC file for the following lib classes: - MemEncryptSevLib (one instance: BaseMemEncryptSevLib) - PlatformFvbLib (two instances: EmuVariableFvbLib, PlatformFvbLibNull) - VirtioLib (one instance: VirtioLib) - VirtioMmioDeviceLib (one instance: VirtioMmioDeviceLib) Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2662 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200407100545.25406-1-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/PvScsiDxe: Support sending SCSI request and receive responseLiran Alon2020-03-301-0/+6
| | | | | | | | | | | | | Implement EXT_SCSI_PASS_THRU.PassThru(). Machines should be able to boot after this commit. Tested with Ubuntu 16.04 guest. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-16-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PvScsiDxe: Report the number of targets and LUNsLiran Alon2020-03-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | Implement EXT_SCSI_PASS_THRU.GetNextTarget() and EXT_SCSI_PASS_THRU.GetNextTargetLun(). ScsiBusDxe scans all MaxTarget * MaxLun possible devices. This can take unnecessarily long for large number of targets. To deal with this, VirtioScsiDxe has defined PCDs to limit the MaxTarget & MaxLun to desired values which gives sufficient performance. It is very important in virtio-scsi as it can have very big MaxTarget & MaxLun. Even though a common PVSCSI device has a default MaxTarget=64 and MaxLun=0, we implement similar mechanism as virtio-scsi for completeness. This may be useful in the future when PVSCSI will have bigger values for MaxTarget and MaxLun. 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-7-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg: create protocol and GUID header for loaded x86 Linux kernelsArd Biesheuvel2020-03-051-26/+27
| | | | | | | | | | In preparation of moving the legacy x86 loading to an implementation of the QEMU load image library class, introduce a protocol header and GUID that we will use to identify legacy loaded x86 Linux kernels in the protocol database. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce QemuLoadImageLib library classArd Biesheuvel2020-03-051-0/+5
| | | | | | | | | | Introduce the QemuLoadImageLib library class that we will instantiate to load the kernel image passed via the QEMU command line using the standard LoadImage boot service. 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: add GUID for the QEMU kernel loader fs media device pathArd Biesheuvel2020-03-051-0/+1
| | | | | | | | | | | | | | | In an upcoming patch, we will introduce a separate DXE driver that exposes the virtual SimpleFileSystem implementation that carries the kernel and initrd passed via the QEMU command line, and a separate library that consumes it, to be incorporated into the boot manager. Since the GUID used for the SimpleFileSystem implementation's device path will no longer be for internal use only, create a well defined GUID to identify the media device path. 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: add definition of LINUX_EFI_INITRD_MEDIA_GUIDArd Biesheuvel2020-03-041-0/+1
| | | | | | | | | | Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions, it can be used in a media device path to specify a Linux style initrd that can be loaded by the OS using the LoadFile2 protocol. 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/Tcg2ConfigPei: introduce a signalling PPI to depex onArd Biesheuvel2020-03-041-0/+5
| | | | | | | | | | | On ARM systems, the TPM does not live at a fixed address, and so we need the platform to discover it first. So introduce a PPI that signals that the TPM address has been discovered and recorded in the appropriate PCD, and make Tcg2ConfigPei depex on it when built for ARM or AARCH64. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce PcdCsmEnable feature flagLaszlo Ersek2020-02-051-0/+5
| | | | | | | | | | | | | | | | | | | | | In the DXE phase and later, it is possible for a module to dynamically determine whether a CSM is enabled. An example can be seen in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM", 2016-05-25). SEC and PEI phase modules cannot check the Legacy BIOS Protocol however. For their sake, introduce a new feature PCD that simply reflects the CSM_ENABLE build flag. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200129214412.2361-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PcdQ35SmramAtDefaultSmbaseLaszlo Ersek2020-02-051-0/+6
| | | | | | | | | | | | | | | | | | | | | For supporting VCPU hotplug with SMM enabled/required, QEMU offers the (dynamically detectable) feature called "SMRAM at default SMBASE". When the feature is enabled, the firmware can lock down the 128 KB range starting at the default SMBASE; that is, the [0x3_0000, 0x4_FFFF] interval. The goal is to shield the very first SMI handler of the hotplugged VCPU from OS influence. Multiple modules in OVMF will have to inter-operate for locking down this range. Introduce a dynamic PCD that will reflect the feature (to be negotiated by PlatformPei), for coordination between drivers. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: Introduce PcdXenGrantFramesAnthony PERARD2019-08-211-0/+3
| | | | | | | | | | | | Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow the same value to be used in a different module. The reason for the number of page to be 4 doesn't exist anymore, so simply remove the comment. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-33-anthony.perard@citrix.com>
* OvmfPkg/Library/XenPlatformLib: New libraryAnthony PERARD2019-08-211-0/+4
| | | | | | | | | | | The purpose of XenPlatformLib is to regroup the few functions that are used in several places to detect if Xen is detected, and to get the XenInfo HOB. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-14-anthony.perard@citrix.com>
* OvmfPkg/XenResetVector: Saving start of day pointer for PVH guestsAnthony PERARD2019-08-211-0/+3
| | | | | | | | | | | | | | | As described in the Xen PVH documentation [1], "ebx: contains the physical memory address where the loader has placed the boot start info structure". To have this pointer saved to be able to use it later in the PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as a signature (for "Xen PVH"). [1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-8-anthony.perard@citrix.com>
* OvmfPkg/OvmfPkg.dec: Add PCD definitions used by copied CSM modulesHao A Wu2019-06-141-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will add the PCD definitions consumed by the duplicated drivers: * VideoDxe * LegacyBiosDxe into the OvmfPkg DEC file. Please note that, instead of adding these PCDs under section: [PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule] as in IntelFrameworkModulePkg.dec file, they are added in section: [PcdsFixedAtBuild] in OvmfPkg.dec instead. 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/OvmfPkg.dec: Add the new include folder for CSM header filesHao A Wu2019-06-141-0/+1
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 The previous file-duplication commit has put all the CSM related header files within folder: OvmfPkg/Csm/Inclue. This commit will update the DEC file to add that folder under the '[Include]' section. 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/OvmfPkg.dec: Add definitions for CSM-related Guid & ProtocolHao A Wu2019-06-141-0/+9
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will add the Guid definitions of the duplicated CSM-related Guids and Protocols from IntelFramework[Module]Pkg. 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: introduce OVMF_PK_KEK1_APP_PREFIX_GUIDLaszlo Ersek2019-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | For the EnrollDefaultKeys application, the hypervisor is expected to add a string entry to the "OEM Strings" (Type 11) SMBIOS table, with the following format: 4e32566d-8e9e-4f52-81d3-5bb9715f9727:<Base64 X509 cert for PK and first KEK> The string representation of the GUID at the front is the "application prefix", in terms of QEMU commit <https://git.qemu.org/?p=qemu.git;a=commit;h=2d6dcbf93fb0>. Introduce this GUID in the usual manner. 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> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg/EnrollDefaultKeys: extract MICROSOFT_VENDOR_GUIDLaszlo Ersek2019-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The GUID 77FA9ABD-0359-4D32-BD60-28F4E78F784B is specified in MSDN, at <https://msdn.microsoft.com/en-us/ie/dn932805(v=vs.94)>, therefore it deserves an entry in the package DEC file, and a header file under "Include/Guid". (Arguably, this GUID declaration / definition could even live under SecurityPkg, but the edk2 tradition has been to hoist GUIDs, protocols/PPIs, and lib classes from OvmfPkg to a core package only when dependent C code is added to the core package.) 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> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC fileHao Wu2019-04-111-0/+26
| | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 According to the DEC file in PcAtChipsetPkg, this commit adds the two 8259-driver-related PCDs into the OvmfPkg DEC file. Please note that, instead of adding the two PCDs under section: [PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule] as in PcAtChipsetPkg.dec file, they are added in section: [PcdsFixedAtBuild] in OvmfPkg.dec instead. 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: Copy Legacy8259 protocol definitions from IntelFrameworkPkgHao Wu2019-04-111-1/+2
| | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 This commit copies the exact Legacy8259 protocol header file from IntelFrameworkPkg to OvmfPkg. Also, the protocol GUID definition is duplicated in the OvmfPkg DEC file. 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 library to track boot option loading/starting on the consoleLaszlo Ersek2019-02-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Introduce the Platform Boot Manager Print Status Code Library (for short, PlatformBmPrintScLib) class for catching and printing the LoadImage() / StartImage() preparations, and return statuses, that are reported by UefiBootManagerLib. In the primary library instance, catch only such status codes that UefiBootManagerLib reports from the same module that contains PlatformBmPrintScLib. The intent is to establish a reporting-printing channel within BdsDxe, between UefiBootManagerLib and PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g. from UiApp's copy of UefiBootManagerLib. 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@linaro.org> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: add QEMU_RAMFB_GUIDGerd Hoffmann2018-06-141-0/+1
| | | | | | | | | Add GUID header file for the QemuRamfbDxe driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce PciCapPciIoLibLaszlo Ersek2018-05-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a library class, and a UEFI_DRIVER lib instance, that are layered on top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend into PciCapLib, for config space access. (Side note: Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and Count is not valid for the PCI configuration header of the PCI controller", this patch doesn't directly document the EFI_UNSUPPORTED error code, for ProtoDevTransferConfig() and its callers ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers to "unspecified error codes". The reason is that in edk2, the PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return EFI_INVALID_PARAMETER for the above situation. Namely, PciIoConfigRead() and PciIoConfigWrite() first call PciIoVerifyConfigAccess(), which indeed produces the standard EFI_UNSUPPORTED error code, if the device's config space is exceeded. However, if PciIoVerifyConfigAccess() passes, and we reach RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge doesn't support extended config space (see commit 014b472053ae3). For all kinds of Limit violations in IO, MMIO, and config space, RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not EFI_UNSUPPORTED. That error code is then propagated up to, and out of, PciIoConfigRead() and PciIoConfigWrite(). [1] MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c [2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c ) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> 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>
* OvmfPkg: introduce PciCapPciSegmentLibLaszlo Ersek2018-05-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a library class, and a BASE lib instance, that are layered on top of PciCapLib, and allow clients to plug a PciSegmentLib backend into PciCapLib, for config space access. (Side note: The "MaxDomain" parameter is provided because, in practice, platforms exist where a PCI Express device may show up on a root bridge such that the root bridge doesn't support access to extended config space. Earlier the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit 014b472053ae3. However, that solution does not apply to the PciSegmentLib class, because: (1) The config space accessor functions of the PciSegmentLib class, such as PciSegmentReadBuffer(), have no way of informing the caller whether access to extended config space actually succeeds. (For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which could in theory benefit from commit 014b472053ae3, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly ignored, because there's no way for the lib instance to propagate it to the PciSegmentLib caller. If the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with indeterminate value.) (2) There is no *general* way for any firmware platform to provide, or use, a PciSegmentLib instance in which access to extended config space always succeeds. In brief, on a platform where config space may be limited to 256 bytes, access to extended config space through PciSegmentLib may invoke undefined behavior; therefore PciCapPciSegmentLib must give platforms a way to prevent such access.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> 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>
* OvmfPkg: introduce PciCapLibLaszlo Ersek2018-05-241-0/+4
| | | | | | | | | | | | | | Add a library class, and a BASE lib instance, to work more easily with PCI capabilities in PCI config space. Functions are provided to parse capabilities lists, and to locate, describe, read and write capabilities. PCI config space access is abstracted away. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: 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>
* 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: Introduce IoMmuAbsent Protocol GUIDBrijesh Singh2017-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Platforms that optionally provide an IOMMU protocol should do so by including a DXE driver (usually called IoMmuDxe) that produces either the IOMMU protocol -- if the underlying capabilities are available --, or gIoMmuAbsentProtocolGuid, to signal that the IOMMU capability detection completed with negative result (i.e., no IOMMU will be available in the system). In turn, DXE drivers (and library instances) that are supposed to use the IOMMU protocol if it is available should add the following to their DEPEX: gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid This ensures these client modules will only be dispatched after IOMMU detection completes (with positive or negative result). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: mention the extended TSEG near the PcdQ35TsegMbytes declarationLaszlo Ersek2017-07-051-3/+4
| | | | | | | | | | PlatformPei can now overwrite PcdQ35TsegMbytes; document this in "OvmfPkg/OvmfPkg.dec". Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: make PcdQ35TsegMbytes dynamicLaszlo Ersek2017-07-051-7/+7
| | | | | | | | | | | | | | We can now make PcdQ35TsegMbytes dynamic, in preparation for the extended TSEG size feature. At the moment we only move the declaration in OvmfPkg.dec from [PcdsFixedAtBuild] to [PcdsDynamic, PcdsDynamicEx], and provide the dynamic defaults (with the same value, 8) in the DSC files if SMM_REQUIRE is TRUE. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: widen PcdQ35TsegMbytes to UINT16Laszlo Ersek2017-07-051-1/+1
| | | | | | | | | | | Widen PcdQ35TsegMbytes to UINT16, in preparation for setting it dynamically to the QEMU-advertized extended TSEG size (which is 16-bits wide). Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnableLaszlo Ersek2017-05-181-1/+0
| | | | | | | | | This PCD is no longer used. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: introduce QemuFwCfgS3Lib classLaszlo Ersek2017-03-141-0/+4
| | | | | | | | | | | | | | | | | | This library class will enable driver modules (a) to query whether S3 support was enabled on the QEMU command line, (b) to produce fw_cfg DMA operations that are to be replayed at S3 resume time. Declare the library class in OvmfPkg/OvmfPkg.dec, and add the library class header under OvmfPkg/Include/Library/. At the moment, the only API we expose is QemuFwCfgS3Enabled(), which we'll first migrate from QemuFwCfgLib. Further interfaces will be added in later patches. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySizeLaszlo Ersek2016-07-151-1/+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/PlatformPei: set PCI IO port aperture dynamicallyLaszlo Ersek2016-05-171-5/+5
| | | | | | | | | | | | | | | | | | Make PcdPciIoBase and PcdPciIoSize dynamic PCDs, and set them in MemMapInitialization(), where we produce our EFI_RESOURCE_IO descriptor HOB. (The PCD is consumed by the core PciHostBridgeDxe driver, through our PciHostBridgeLib instance.) Take special care to keep the GCD IO space map unchanged on all platforms OVMF runs on. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 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: Gabriel Somlo <somlo@cmu.edu>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-27 23:43:44 +0000