2010-02-24 00:58:38 +01:00
|
|
|
## @file
|
2009-05-27 23:10:18 +02:00
|
|
|
# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
|
|
|
|
|
#
|
OvmfPkg: fix DEC spec violation introduced by Bhyve addition
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>
2020-08-01 17:50:24 +02:00
|
|
|
# Copyright (c) 2020, Rebecca Cran <rebecca@bsdio.com>
|
2019-04-02 09:26:03 +02:00
|
|
|
# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
|
OvmfPkg: fix DEC spec violation introduced by Bhyve addition
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>
2020-08-01 17:50:24 +02:00
|
|
|
# Copyright (c) 2014, Pluribus Networks, Inc.
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2019-04-04 01:06:33 +02:00
|
|
|
# SPDX-License-Identifier: BSD-2-Clause-Patent
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2010-02-24 00:58:38 +01:00
|
|
|
##
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
[Defines]
|
2011-06-28 04:24:46 +02:00
|
|
|
DEC_SPECIFICATION = 0x00010005
|
2009-05-27 23:10:18 +02:00
|
|
|
PACKAGE_NAME = OvmfPkg
|
|
|
|
|
PACKAGE_GUID = 2daf5f34-50e5-4b9d-b8e3-5562334d87e5
|
|
|
|
|
PACKAGE_VERSION = 0.1
|
|
|
|
|
|
2009-09-16 18:28:55 +02:00
|
|
|
[Includes]
|
|
|
|
|
Include
|
2019-05-15 08:36:35 +02:00
|
|
|
Csm/Include
|
2009-09-16 18:28:55 +02:00
|
|
|
|
Clean up DEC files:
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-09 19:50:40 +02:00
|
|
|
[LibraryClasses]
|
OvmfPkg: fix DEC spec violation introduced by Bhyve addition
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>
2020-08-01 17:50:24 +02:00
|
|
|
## @libraryclass Access bhyve's firmware control interface.
|
|
|
|
|
BhyveFwCtlLib|Include/Library/BhyveFwCtlLib.h
|
2021-07-01 14:19:35 +02:00
|
|
|
|
|
|
|
|
## @libraryclass Verify blobs read from the VMM
|
|
|
|
|
BlobVerifierLib|Include/Library/BlobVerifierLib.h
|
OvmfPkg: fix DEC spec violation introduced by Bhyve addition
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>
2020-08-01 17:50:24 +02:00
|
|
|
|
2012-11-02 19:26:48 +01:00
|
|
|
## @libraryclass Loads and boots a Linux kernel image
|
|
|
|
|
#
|
|
|
|
|
LoadLinuxLib|Include/Library/LoadLinuxLib.h
|
|
|
|
|
|
2020-04-07 12:05:45 +02:00
|
|
|
## @libraryclass Declares helper functions for Secure Encrypted
|
|
|
|
|
# Virtualization (SEV) guests.
|
|
|
|
|
MemEncryptSevLib|Include/Library/MemEncryptSevLib.h
|
|
|
|
|
|
Clean up DEC files:
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-09 19:50:40 +02:00
|
|
|
## @libraryclass Save and restore variables using a file
|
|
|
|
|
#
|
|
|
|
|
NvVarsFileLib|Include/Library/NvVarsFileLib.h
|
|
|
|
|
|
2018-04-28 23:22:11 +02:00
|
|
|
## @libraryclass Provides services to work with PCI capabilities in PCI
|
|
|
|
|
# config space.
|
|
|
|
|
PciCapLib|Include/Library/PciCapLib.h
|
|
|
|
|
|
OvmfPkg: introduce PciCapPciIoLib
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>
2018-04-28 23:23:10 +02:00
|
|
|
## @libraryclass Layered on top of PciCapLib, allows clients to plug an
|
|
|
|
|
# EFI_PCI_IO_PROTOCOL backend into PciCapLib, for config
|
|
|
|
|
# space access.
|
|
|
|
|
PciCapPciIoLib|Include/Library/PciCapPciIoLib.h
|
|
|
|
|
|
OvmfPkg: introduce PciCapPciSegmentLib
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>
2018-04-28 23:22:59 +02:00
|
|
|
## @libraryclass Layered on top of PciCapLib, allows clients to plug a
|
|
|
|
|
# PciSegmentLib backend into PciCapLib, for config space
|
|
|
|
|
# access.
|
|
|
|
|
PciCapPciSegmentLib|Include/Library/PciCapPciSegmentLib.h
|
|
|
|
|
|
2021-01-19 02:12:52 +01:00
|
|
|
## @libraryclass Provide common utility functions to PciHostBridgeLib
|
|
|
|
|
# instances in ArmVirtPkg and OvmfPkg.
|
|
|
|
|
PciHostBridgeUtilityLib|Include/Library/PciHostBridgeUtilityLib.h
|
|
|
|
|
|
2017-11-22 21:37:07 +01:00
|
|
|
## @libraryclass Register a status code handler for printing the Boot
|
|
|
|
|
# Manager's LoadImage() and StartImage() preparations, and
|
|
|
|
|
# return codes, to the UEFI console.
|
|
|
|
|
PlatformBmPrintScLib|Include/Library/PlatformBmPrintScLib.h
|
|
|
|
|
|
2020-04-07 12:05:45 +02:00
|
|
|
## @libraryclass Customize FVB2 protocol member functions for a platform.
|
|
|
|
|
PlatformFvbLib|Include/Library/PlatformFvbLib.h
|
|
|
|
|
|
2012-05-31 01:14:38 +02:00
|
|
|
## @libraryclass Access QEMU's firmware configuration interface
|
|
|
|
|
#
|
|
|
|
|
QemuFwCfgLib|Include/Library/QemuFwCfgLib.h
|
|
|
|
|
|
2017-02-22 01:59:41 +01:00
|
|
|
## @libraryclass S3 support for QEMU fw_cfg
|
|
|
|
|
#
|
|
|
|
|
QemuFwCfgS3Lib|Include/Library/QemuFwCfgS3Lib.h
|
|
|
|
|
|
2020-04-24 09:53:47 +02:00
|
|
|
## @libraryclass Parse the contents of named fw_cfg files as simple
|
|
|
|
|
# (scalar) data types.
|
|
|
|
|
QemuFwCfgSimpleParserLib|Include/Library/QemuFwCfgSimpleParserLib.h
|
|
|
|
|
|
2015-01-02 13:07:57 +01:00
|
|
|
## @libraryclass Rewrite the BootOrder NvVar based on QEMU's "bootorder"
|
|
|
|
|
# fw_cfg file.
|
|
|
|
|
#
|
|
|
|
|
QemuBootOrderLib|Include/Library/QemuBootOrderLib.h
|
|
|
|
|
|
2020-02-28 17:04:01 +01:00
|
|
|
## @libraryclass Load a kernel image and command line passed to QEMU via
|
|
|
|
|
# the command line
|
|
|
|
|
#
|
|
|
|
|
QemuLoadImageLib|Include/Library/QemuLoadImageLib.h
|
|
|
|
|
|
Clean up DEC files:
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-09 19:50:40 +02:00
|
|
|
## @libraryclass Serialize (and deserialize) variables
|
|
|
|
|
#
|
|
|
|
|
SerializeVariablesLib|Include/Library/SerializeVariablesLib.h
|
|
|
|
|
|
2020-04-07 12:05:45 +02:00
|
|
|
## @libraryclass Declares utility functions for virtio device drivers.
|
|
|
|
|
VirtioLib|Include/Library/VirtioLib.h
|
|
|
|
|
|
|
|
|
|
## @libraryclass Install Virtio Device Protocol instances on virtio-mmio
|
|
|
|
|
# transports.
|
|
|
|
|
VirtioMmioDeviceLib|Include/Library/VirtioMmioDeviceLib.h
|
|
|
|
|
|
2015-02-28 21:32:39 +01:00
|
|
|
## @libraryclass Invoke Xen hypercalls
|
|
|
|
|
#
|
|
|
|
|
XenHypercallLib|Include/Library/XenHypercallLib.h
|
|
|
|
|
|
2015-02-28 21:34:16 +01:00
|
|
|
## @libraryclass Manage XenBus device path and I/O handles
|
|
|
|
|
#
|
|
|
|
|
XenIoMmioLib|Include/Library/XenIoMmioLib.h
|
|
|
|
|
|
2019-08-13 13:30:57 +02:00
|
|
|
## @libraryclass Get information about Xen
|
|
|
|
|
#
|
|
|
|
|
XenPlatformLib|Include/Library/XenPlatformLib.h
|
|
|
|
|
|
2010-02-24 00:58:38 +01:00
|
|
|
[Guids]
|
2020-03-05 11:59:57 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 0x62, 0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
|
|
|
|
|
gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
|
|
|
|
|
gOvmfPkKek1AppPrefixGuid = {0x4e32566d, 0x8e9e, 0x4f52, {0x81, 0xd3, 0x5b, 0xb9, 0x71, 0x5f, 0x97, 0x27}}
|
|
|
|
|
gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
|
|
|
|
|
gVirtioMmioTransportGuid = {0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
|
|
|
|
|
gQemuRamfbGuid = {0x557423a1, 0x63ab, 0x406c, {0xbe, 0x7e, 0x91, 0xcd, 0xbc, 0x08, 0xc4, 0x57}}
|
|
|
|
|
gXenBusRootDeviceGuid = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
|
|
|
|
|
gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
|
|
|
|
|
gMicrosoftVendorGuid = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
|
|
|
|
|
gEfiLegacyBiosGuid = {0x2E3044AC, 0x879F, 0x490F, {0x97, 0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
|
|
|
|
|
gEfiLegacyDevOrderVariableGuid = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
|
|
|
|
|
gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
|
2020-11-30 21:28:16 +01:00
|
|
|
gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
|
2020-12-16 02:41:46 +01:00
|
|
|
gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2020-02-26 20:05:06 +01:00
|
|
|
[Ppis]
|
|
|
|
|
# PPI whose presence in the PPI database signals that the TPM base address
|
|
|
|
|
# has been discovered and recorded
|
2020-03-05 11:59:57 +01:00
|
|
|
gOvmfTpmDiscoveredPpiGuid = {0xb9a61ad0, 0x2802, 0x41f3, {0xb5, 0x13, 0x96, 0x51, 0xce, 0x6b, 0xd5, 0x75}}
|
2020-02-26 20:05:06 +01:00
|
|
|
|
2021-04-29 19:12:12 +02:00
|
|
|
# This PPI signals that accessing the MMIO range of the TPM is possible in
|
|
|
|
|
# the PEI phase, regardless of memory encryption
|
|
|
|
|
gOvmfTpmMmioAccessiblePpiGuid = {0x35c84ff2, 0x7bfe, 0x453d, {0x84, 0x5f, 0x68, 0x3a, 0x49, 0x2c, 0xf7, 0xb7}}
|
|
|
|
|
|
2010-03-21 01:33:59 +01:00
|
|
|
[Protocols]
|
2020-03-05 11:59:57 +01:00
|
|
|
gVirtioDeviceProtocolGuid = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
|
|
|
|
|
gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
|
|
|
|
|
gXenIoProtocolGuid = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
|
|
|
|
|
gIoMmuAbsentProtocolGuid = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
|
|
|
|
|
gEfiLegacy8259ProtocolGuid = {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
|
|
|
|
|
gEfiFirmwareVolumeProtocolGuid = {0x389F751F, 0x1838, 0x4388, {0x83, 0x90, 0xcd, 0x81, 0x54, 0xbd, 0x27, 0xf8}}
|
|
|
|
|
gEfiIsaAcpiProtocolGuid = {0x64a892dc, 0x5561, 0x4536, {0x92, 0xc7, 0x79, 0x9b, 0xfc, 0x18, 0x33, 0x55}}
|
|
|
|
|
gEfiIsaIoProtocolGuid = {0x7ee2bd44, 0x3da0, 0x11d4, {0x9a, 0x38, 0x0, 0x90, 0x27, 0x3f, 0xc1, 0x4d}}
|
|
|
|
|
gEfiLegacyBiosProtocolGuid = {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
|
|
|
|
|
gEfiLegacyBiosPlatformProtocolGuid = {0x783658a3, 0x4172, 0x4421, {0xa2, 0x99, 0xe0, 0x09, 0x07, 0x9c, 0x0c, 0xb4}}
|
|
|
|
|
gEfiLegacyInterruptProtocolGuid = {0x31ce593d, 0x108a, 0x485d, {0xad, 0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
|
|
|
|
|
gEfiVgaMiniPortProtocolGuid = {0xc7735a2f, 0x88f5, 0x4882, {0xae, 0x63, 0xfa, 0xac, 0x8c, 0x8b, 0x86, 0xb3}}
|
|
|
|
|
gOvmfLoadedX86LinuxKernelProtocolGuid = {0xa3edc05d, 0xb618, 0x4ff6, {0x95, 0x52, 0x76, 0xd7, 0x88, 0x63, 0x43, 0xc8}}
|
2010-03-21 01:33:59 +01:00
|
|
|
|
2009-09-26 09:15:48 +02:00
|
|
|
[PcdsFixedAtBuild]
|
2014-01-21 20:39:13 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize|0x0|UINT32|1
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|0x0|UINT32|0x15
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize|0x0|UINT32|0x16
|
2009-09-26 09:15:48 +02:00
|
|
|
|
2012-07-26 18:36:39 +02:00
|
|
|
## This flag is used to control the destination port for PlatformDebugLibIoPort
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0x402|UINT16|4
|
|
|
|
|
|
2012-10-18 19:07:48 +02:00
|
|
|
## When VirtioScsiDxe is instantiated for a HBA, the numbers of targets and
|
|
|
|
|
# LUNs are retrieved from the host during virtio-scsi setup.
|
|
|
|
|
# MdeModulePkg/Bus/Scsi/ScsiBusDxe then scans all MaxTarget * MaxLun
|
|
|
|
|
# possible devices. This can take extremely long, for example with
|
|
|
|
|
# MaxTarget=255 and MaxLun=16383. The *inclusive* constants below limit
|
|
|
|
|
# MaxTarget and MaxLun, independently, should the host report higher values,
|
|
|
|
|
# so that scanning the number of devices given by their product is still
|
|
|
|
|
# acceptably fast.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxTargetLimit|31|UINT16|6
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxLunLimit|7|UINT32|7
|
|
|
|
|
|
2020-03-28 21:00:49 +01:00
|
|
|
## Sets the *inclusive* number of targets and LUNs that PvScsi exposes for
|
|
|
|
|
# scan by ScsiBusDxe.
|
|
|
|
|
# As specified above for VirtioScsi, ScsiBusDxe scans all MaxTarget * MaxLun
|
|
|
|
|
# possible devices, which can take extremely long. Thus, the below constants
|
|
|
|
|
# are used so that scanning the number of devices given by their product
|
|
|
|
|
# is still acceptably fast.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPvScsiMaxTargetLimit|64|UINT8|0x36
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPvScsiMaxLunLimit|0|UINT8|0x37
|
|
|
|
|
|
2020-03-28 21:00:58 +01:00
|
|
|
## After PvScsiDxe sends a SCSI request to the device, it waits for
|
|
|
|
|
# the request completion in a polling loop.
|
|
|
|
|
# This constant defines how many micro-seconds to wait between each
|
|
|
|
|
# polling loop iteration.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPvScsiWaitForCmpStallInUsecs|5|UINT32|0x38
|
|
|
|
|
|
2020-05-04 23:06:01 +02:00
|
|
|
## Set the *inclusive* number of targets that MptScsi exposes for scan
|
|
|
|
|
# by ScsiBusDxe.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiMaxTargetLimit|7|UINT8|0x39
|
|
|
|
|
|
2020-05-04 23:06:06 +02:00
|
|
|
## Microseconds to stall between polling for MptScsi request result
|
2020-07-15 10:20:31 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiStallPerPollUsec|5|UINT32|0x3a
|
2020-05-04 23:06:06 +02:00
|
|
|
|
2020-07-17 08:11:25 +02:00
|
|
|
## Set the *inclusive* number of targets and LUNs that LsiScsi exposes for
|
|
|
|
|
# scan by ScsiBusDxe.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdLsiScsiMaxTargetLimit|7|UINT8|0x3b
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdLsiScsiMaxLunLimit|0|UINT8|0x3c
|
|
|
|
|
|
2020-07-17 08:11:29 +02:00
|
|
|
## Microseconds to stall between polling for LsiScsi request result
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdLsiScsiStallPerPollUsec|5|UINT32|0x3d
|
|
|
|
|
|
2013-11-12 19:34:11 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase|0x0|UINT32|0x8
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize|0x0|UINT32|0x9
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize|0x0|UINT32|0xa
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize|0|UINT32|0xb
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase|0x0|UINT32|0xc
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase|0x0|UINT32|0xd
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase|0x0|UINT32|0xe
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress|0x0|UINT32|0xf
|
2014-01-21 20:38:34 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|0x0|UINT32|0x11
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize|0x0|UINT32|0x12
|
2014-01-21 20:38:43 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|0x0|UINT32|0x13
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize|0x0|UINT32|0x14
|
2014-03-04 09:03:23 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|0x0|UINT32|0x18
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize|0x0|UINT32|0x19
|
OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3
OVMF's SecMain is unique in the sense that it links against the following
two libraries *in combination*:
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/
LzmaCustomDecompressLib.inf
- MdePkg/Library/BaseExtractGuidedSectionLib/
BaseExtractGuidedSectionLib.inf
The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.
BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.
LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is
gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF
When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:
LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
GetExtractGuidedSectionHandlerInfo()
PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS
Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:
SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]
SecStartupPhase2()
FindAndReportEntryPoints()
FindPeiCoreImageBase()
DecompressMemFvs()
ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c]
ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c]
Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.
This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).
This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:
crash> rd -8 -p 1000000 0x50
1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3..............
1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8.......
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
vs.
crash> rd -8 -p 1000000 0x50
1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... .......
1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ...............
1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{....
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.
Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.
Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between
PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
and
PcdOvmfSecPeiTempRamBase == 8256 KB.
- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).
- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
supported and we're not currently resuming.
The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):
sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32
PcdMaximumGuidedExtractHandler * (
sizeof(GUID) + // 16
sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8
sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8
)
OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.
Regarding the lifecycle of the new area:
(a) when and how it is initialized after first boot of the VM
The library linked into SecMain finds that the area lacks the signature.
It initializes the signature, plus the rest of the structure. This is
independent of S3 support.
Consumption of the area is also limited to SEC (but consumption does
depend on full-config-boot).
(b) how it is protected from memory allocations during DXE
It is not, in the general case; and we don't need to. Nothing else links
against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.
(c) how it is protected from the OS
When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().
When S3 is not supported, the range is not protected.
(d) how it is accessed on the S3 resume path
Examined by the library linked into SecMain. Registrations update the
table in-place (based on GUID matches).
(e) how it is accessed on the warm reset path
If S3 is enabled, then the OS won't damage the table (due to (c)), hence
see (d).
If S3 is unsupported, then the OS may or may not overwrite the
signature. (It likely will.) This is identical to the pre-patch status.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15433 6f19259b-4bc3-4df7-8a09-765794883524
2014-04-05 23:26:09 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
|
OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer
The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).
DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.
Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19036 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:20 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
|
2013-11-12 19:34:11 +01:00
|
|
|
|
2019-04-02 09:28:50 +02:00
|
|
|
## Pcd8259LegacyModeMask defines the default mask value for platform. This
|
|
|
|
|
# value is determined.
|
|
|
|
|
# 1) If platform only support pure UEFI, value should be set to 0xFFFF or
|
|
|
|
|
# 0xFFFE; Because only clock interrupt is allowed in legacy mode in pure
|
|
|
|
|
# UEFI platform.
|
|
|
|
|
# 2) If platform install CSM and use thunk module:
|
|
|
|
|
# a) If thunk call provided by CSM binary requires some legacy interrupt
|
|
|
|
|
# support, the corresponding bit should be opened as 0.
|
|
|
|
|
# For example, if keyboard interfaces provided CSM binary use legacy
|
|
|
|
|
# keyboard interrupt in 8259 bit 1, then the value should be set to
|
|
|
|
|
# 0xFFFC.
|
|
|
|
|
# b) If all thunk call provied by CSM binary do not require legacy
|
|
|
|
|
# interrupt support, value should be set to 0xFFFF or 0xFFFE.
|
|
|
|
|
#
|
|
|
|
|
# The default value of legacy mode mask could be changed by
|
|
|
|
|
# EFI_LEGACY_8259_PROTOCOL->SetMask(). But it is rarely need change it
|
|
|
|
|
# except some special cases such as when initializing the CSM binary, it
|
|
|
|
|
# should be set to 0xFFFF to mask all legacy interrupt. Please restore the
|
|
|
|
|
# original legacy mask value if changing is made for these special case.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeMask|0xFFFF|UINT16|0x3
|
|
|
|
|
|
|
|
|
|
## Pcd8259LegacyModeEdgeLevel defines the default edge level for legacy
|
|
|
|
|
# mode's interrrupt controller.
|
|
|
|
|
# For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0000|UINT16|0x5
|
|
|
|
|
|
2019-05-15 08:39:46 +02:00
|
|
|
## Indicates if BiosVideo driver will switch to 80x25 Text VGA Mode when
|
|
|
|
|
# exiting boot service.
|
|
|
|
|
# TRUE - Switch to Text VGA Mode.
|
|
|
|
|
# FALSE - Does not switch to Text VGA Mode.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoSetTextVgaModeEnable|FALSE|BOOLEAN|0x28
|
|
|
|
|
|
|
|
|
|
## Indicates if BiosVideo driver will check for VESA BIOS Extension service
|
|
|
|
|
# support.
|
|
|
|
|
# TRUE - Check for VESA BIOS Extension service.
|
|
|
|
|
# FALSE - Does not check for VESA BIOS Extension service.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVbeEnable|TRUE|BOOLEAN|0x29
|
|
|
|
|
|
|
|
|
|
## Indicates if BiosVideo driver will check for VGA service support.
|
|
|
|
|
# NOTE: If both PcdBiosVideoCheckVbeEnable and PcdBiosVideoCheckVgaEnable
|
|
|
|
|
# are set to FALSE, that means Graphics Output protocol will not be
|
|
|
|
|
# installed, the VGA miniport protocol will be installed instead.
|
|
|
|
|
# TRUE - Check for VGA service.<BR>
|
|
|
|
|
# FALSE - Does not check for VGA service.<BR>
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVgaEnable|TRUE|BOOLEAN|0x2a
|
|
|
|
|
|
|
|
|
|
## Indicates if memory space for legacy region will be set as cacheable.
|
|
|
|
|
# TRUE - Set cachebility for legacy region.
|
|
|
|
|
# FALSE - Does not set cachebility for legacy region.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion|TRUE|BOOLEAN|0x2b
|
|
|
|
|
|
|
|
|
|
## Specify memory size with bytes to reserve EBDA below 640K for OPROM.
|
|
|
|
|
# The value should be a multiple of 4KB.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdEbdaReservedMemorySize|0x8000|UINT32|0x2c
|
|
|
|
|
|
|
|
|
|
## Specify memory base address for OPROM to find free memory.
|
|
|
|
|
# Some OPROMs do not use EBDA or PMM to allocate memory for its usage,
|
|
|
|
|
# instead they find the memory filled with zero from 0x20000.
|
|
|
|
|
# The value should be a multiple of 4KB.
|
|
|
|
|
# The range should be below the EBDA reserved range from
|
|
|
|
|
# (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
|
|
|
|
|
# CONVENTIONAL_MEMORY_TOP.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemoryBase|0x60000|UINT32|0x2d
|
|
|
|
|
|
|
|
|
|
## Specify memory size with bytes for OPROM to find free memory.
|
|
|
|
|
# The value should be a multiple of 4KB. And the range should be below the
|
|
|
|
|
# EBDA reserved range from
|
|
|
|
|
# (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
|
|
|
|
|
# CONVENTIONAL_MEMORY_TOP.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemorySize|0x28000|UINT32|0x2e
|
|
|
|
|
|
|
|
|
|
## Specify the end of address below 1MB for the OPROM.
|
|
|
|
|
# The last shadowed OpROM should not exceed this address.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdEndOpromShadowAddress|0xdffff|UINT32|0x2f
|
|
|
|
|
|
|
|
|
|
## Specify the low PMM (Post Memory Manager) size with bytes below 1MB.
|
|
|
|
|
# The value should be a multiple of 4KB.
|
|
|
|
|
# @Prompt Low PMM (Post Memory Manager) Size
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdLowPmmMemorySize|0x10000|UINT32|0x30
|
|
|
|
|
|
|
|
|
|
## Specify the high PMM (Post Memory Manager) size with bytes above 1MB.
|
|
|
|
|
# The value should be a multiple of 4KB.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdHighPmmMemorySize|0x400000|UINT32|0x31
|
|
|
|
|
|
2019-08-13 13:30:51 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
|
|
|
|
|
|
2019-08-13 13:31:16 +02:00
|
|
|
## Number of page frames to use for storing grant table entries.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
|
|
|
|
|
|
OvmfPkg: Create a GHCB page for use during Sec phase
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>
2020-08-12 22:21:40 +02:00
|
|
|
## Specify the extra page table needed to mark the GHCB as unencrypted.
|
|
|
|
|
# The value should be a multiple of 4KB for each.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|0x0|UINT32|0x3e
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize|0x0|UINT32|0x3f
|
|
|
|
|
|
|
|
|
|
## The base address of the SEC GHCB page used by SEV-ES.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0|UINT32|0x40
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0|UINT32|0x41
|
2021-01-07 19:48:23 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|0|UINT32|0x44
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize|0|UINT32|0x45
|
OvmfPkg: Create a GHCB page for use during Sec phase
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>
2020-08-12 22:21:40 +02:00
|
|
|
|
2020-11-30 21:28:17 +01:00
|
|
|
## The base address and size of the SEV Launch Secret Area provisioned
|
|
|
|
|
# after remote attestation. If this is set in the .fdf, the platform
|
|
|
|
|
# is responsible for protecting the area from DXE phase overwrites.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|0x0|UINT32|0x42
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize|0x0|UINT32|0x43
|
|
|
|
|
|
2021-01-16 23:42:44 +01:00
|
|
|
## The base address and size of a hash table confirming allowed
|
|
|
|
|
# parameters to be passed in via the Qemu firmware configuration
|
|
|
|
|
# device
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|0x0|UINT32|0x47
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize|0x0|UINT32|0x48
|
|
|
|
|
|
OvmfPkg: introduce a common work area
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Both the TDX and SEV support needs to reserve a page in MEMFD as a work
area. The page will contain meta data specific to the guest type.
Currently, the SEV-ES support reserves a page in MEMFD
(PcdSevEsWorkArea) for the work area. This page can be reused as a TDX
work area when Intel TDX is enabled.
Based on the discussion [1], it was agreed to rename the SevEsWorkArea
to the OvmfWorkArea, and add a header that can be used to indicate the
work area type.
[1] https://edk2.groups.io/g/devel/message/78262?p=,,,20,0,0,0::\
created,0,SNP,20,2,0,84476064
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
2021-08-17 15:46:49 +02:00
|
|
|
## The base address and size of the work area used during the SEC
|
|
|
|
|
# phase by the SEV and TDX supports.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|0|UINT32|0x49
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize|0|UINT32|0x50
|
|
|
|
|
|
|
|
|
|
## The work area contains a fixed size header in the Include/WorkArea.h.
|
|
|
|
|
# The size of this header is used early boot, and is provided through
|
|
|
|
|
# a fixed PCD. It need to be kept in sync with any changes to the
|
|
|
|
|
# header definition.
|
2021-09-17 07:37:24 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader|4|UINT32|0x51
|
OvmfPkg: introduce a common work area
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Both the TDX and SEV support needs to reserve a page in MEMFD as a work
area. The page will contain meta data specific to the guest type.
Currently, the SEV-ES support reserves a page in MEMFD
(PcdSevEsWorkArea) for the work area. This page can be reused as a TDX
work area when Intel TDX is enabled.
Based on the discussion [1], it was agreed to rename the SevEsWorkArea
to the OvmfWorkArea, and add a header that can be used to indicate the
work area type.
[1] https://edk2.groups.io/g/devel/message/78262?p=,,,20,0,0,0::\
created,0,SNP,20,2,0,84476064
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
2021-08-17 15:46:49 +02:00
|
|
|
|
2021-09-28 04:47:29 +02:00
|
|
|
## The base address and size of the TDX Cfv base and size.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdCfvBase|0|UINT32|0x52
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataOffset|0|UINT32|0x53
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataSize|0|UINT32|0x54
|
|
|
|
|
|
|
|
|
|
## The base address and size of the TDX Bfv base and size.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase|0|UINT32|0x55
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataOffset|0|UINT32|0x56
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataSize|0|UINT32|0x57
|
OvmfPkg: introduce a common work area
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Both the TDX and SEV support needs to reserve a page in MEMFD as a work
area. The page will contain meta data specific to the guest type.
Currently, the SEV-ES support reserves a page in MEMFD
(PcdSevEsWorkArea) for the work area. This page can be reused as a TDX
work area when Intel TDX is enabled.
Based on the discussion [1], it was agreed to rename the SevEsWorkArea
to the OvmfWorkArea, and add a header that can be used to indicate the
work area type.
[1] https://edk2.groups.io/g/devel/message/78262?p=,,,20,0,0,0::\
created,0,SNP,20,2,0,84476064
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
2021-08-17 15:46:49 +02:00
|
|
|
|
2021-12-09 04:27:33 +01:00
|
|
|
## The base address and size of the SEV-SNP Secrets Area that contains
|
|
|
|
|
# the VM platform communication key used to send and recieve the
|
|
|
|
|
# messages to the PSP. If this is set in the .fdf, the platform
|
|
|
|
|
# is responsible to reserve this area from DXE phase overwrites.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase|0|UINT32|0x58
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize|0|UINT32|0x59
|
|
|
|
|
|
2021-12-09 04:27:34 +01:00
|
|
|
## The base address and size of a CPUID Area that contains the hypervisor
|
|
|
|
|
# provided CPUID results. In the case of SEV-SNP, the CPUID results are
|
|
|
|
|
# filtered by the SEV-SNP firmware. If this is set in the .fdf, the
|
|
|
|
|
# platform is responsible to reserve this area from DXE phase overwrites.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|0|UINT32|0x60
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize|0|UINT32|0x61
|
|
|
|
|
|
2011-05-05 18:15:35 +02:00
|
|
|
[PcdsDynamic, PcdsDynamicEx]
|
2010-11-02 06:27:15 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
|
2013-11-12 19:35:23 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
|
2014-11-14 01:37:39 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0|UINT16|0x1b
|
2015-08-06 12:13:55 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE|BOOLEAN|0x21
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2016-05-09 22:39:44 +02:00
|
|
|
## The IO port aperture shared by all PCI root bridges.
|
|
|
|
|
#
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase|0x0|UINT64|0x22
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize|0x0|UINT64|0x23
|
|
|
|
|
|
2016-02-26 16:29:19 +01:00
|
|
|
## The 32-bit MMIO aperture shared by all PCI root bridges.
|
|
|
|
|
#
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0|UINT64|0x24
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0|UINT64|0x25
|
|
|
|
|
|
OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXE
The main observation about the 64-bit PCI host aperture is that it is the
highest part of the useful address space. It impacts the top of the GCD
memory space map, and, consequently, our maximum address width calculation
for the CPU HOB too.
Thus, modify the GetFirstNonAddress() function to consider the following
areas above the high RAM, while calculating the first non-address (i.e.,
the highest inclusive address, plus one):
- the memory hotplug area (optional, the size comes from QEMU),
- the 64-bit PCI host aperture (we set a default size).
While computing the first non-address, capture the base and the size of
the 64-bit PCI host aperture at once in PCDs, since they are natural parts
of the calculation.
(Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path
(see the InitializePlatform() -> MemMapInitialization() condition), nor
are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them,
through our PciHostBridgeLib instance.)
Set 32GB as the default size for the aperture. Issue#59 mentions the
NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these
cards may have 24GB of memory (probably 16GB + 8GB BARs).
As a strictly experimental feature, the user can specify the size of the
aperture (in MB) as well, with the QEMU option
-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536
The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning
that the property is experimental, unstable, and might go away any time.
Gerd has proposed heuristics for sizing the aperture automatically (based
on 1GB page support and PCPU address width), but such should be delayed to
a later patch (which may very well back out "X-PciMmio64Mb" then).
For "everyday" guests, the 32GB default for the aperture size shouldn't
impact the PEI memory demand (the size of the page tables that the DXE IPL
PEIM builds). Namely, we've never reported narrower than 36-bit addresses;
the DXE IPL PEIM has always built page tables for 64GB at least.
For the aperture to bump the address width above 36 bits, either the guest
must have quite a bit of memory itself (in which case the additional PEI
memory demand shouldn't matter), or the user must specify a large aperture
manually with "X-PciMmio64Mb" (and then he or she is also responsible for
giving enough RAM to the VM, to satisfy the PEI memory demand).
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ref: https://github.com/tianocore/edk2/issues/59
Ref: http://www.nvidia.com/object/tesla-servers.html
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-04 19:30:45 +01:00
|
|
|
## The 64-bit MMIO aperture shared by all PCI root bridges.
|
|
|
|
|
#
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0|UINT64|0x26
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0|UINT64|0x27
|
|
|
|
|
|
2017-07-04 13:52:34 +02:00
|
|
|
## The following setting controls how many megabytes we configure as TSEG on
|
2017-07-04 15:09:51 +02:00
|
|
|
# Q35, for SMRAM purposes. Permitted defaults are: 1, 2, 8. Other defaults
|
|
|
|
|
# cause undefined behavior. During boot, the PCD is updated by PlatformPei
|
|
|
|
|
# to reflect the extended TSEG size, if one is advertized by QEMU.
|
2017-07-04 13:52:34 +02:00
|
|
|
#
|
2017-07-04 15:09:51 +02:00
|
|
|
# This PCD is only accessed if PcdSmmSmramRequire is TRUE (see below).
|
2017-07-04 13:52:34 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8|UINT16|0x20
|
|
|
|
|
|
2019-09-20 10:56:47 +02:00
|
|
|
## Set to TRUE by PlatformPei if the Q35 board supports the "SMRAM at default
|
|
|
|
|
# SMBASE" feature.
|
|
|
|
|
#
|
|
|
|
|
# This PCD is only accessed if PcdSmmSmramRequire is TRUE (see below).
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE|BOOLEAN|0x34
|
|
|
|
|
|
2021-03-12 07:26:51 +01:00
|
|
|
## This PCD adds a communication channel between OVMF's SmmCpuFeaturesLib
|
|
|
|
|
# instance in PiSmmCpuDxeSmm, and CpuHotplugSmm.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdCpuHotEjectDataAddress|0|UINT64|0x46
|
|
|
|
|
|
2012-03-09 18:38:21 +01:00
|
|
|
[PcdsFeatureFlag]
|
2015-01-02 13:08:02 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
|
2015-01-02 13:08:19 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
|
2015-11-30 19:41:10 +01:00
|
|
|
|
|
|
|
|
## This feature flag enables SMM/SMRAM support. Note that it also requires
|
|
|
|
|
# such support from the underlying QEMU instance; if that support is not
|
|
|
|
|
# present, the firmware will reject continuing after a certain point.
|
|
|
|
|
#
|
|
|
|
|
# The flag also acts as a general "security switch"; when TRUE, many
|
|
|
|
|
# components will change behavior, with the goal of preventing a malicious
|
|
|
|
|
# runtime OS from tampering with firmware structures (special memory ranges
|
|
|
|
|
# used by OVMF, the varstore pflash chip, LockBox etc).
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|FALSE|BOOLEAN|0x1e
|
2020-01-29 19:53:18 +01:00
|
|
|
|
|
|
|
|
## Informs modules (including pre-DXE-phase modules) whether the platform
|
|
|
|
|
# firmware contains a CSM (Compatibility Support Module).
|
|
|
|
|
#
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|FALSE|BOOLEAN|0x35
|
