All these platforms statically inherit PcdPciDisableBusEnumeration=FALSE
from "MdeModulePkg.dec". Remove the the PCD and everything that depends on
it from the PciHostBridgeLib instance. Namely, remove the logic that
determines the root bridge apertures by (a) scanning the entire bus,
device and function number space, and (b) parsing the BAR values that were
pre-set by the Bhyve or Xen machinery.
"XenSupport.c" used to be listed explicitly in "Maintainers.txt", remove
it from that spot too.
Cc: Andrew Fish <afish@apple.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-33-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:34 +0000 (22:14 +0200)]
OvmfPkg/OvmfXen: consume PciHostBridgeLibScan
Switch the OvmfXen platform from the "OvmfPkg/PciHostBridgeLib" instance
to the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op
functionally; we'll customize the "PciHostBridgeLibScan" instance later.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-32-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:33 +0000 (22:14 +0200)]
OvmfPkg/Bhyve: consume PciHostBridgeLibScan
Switch the Bhyve platform from the "OvmfPkg/PciHostBridgeLib" instance to
the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op
functionally; we'll customize the "PciHostBridgeLibScan" instance later.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-31-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:32 +0000 (22:14 +0200)]
OvmfPkg/PciHostBridgeLibScan: create from PciHostBridgeLib
Create an almost verbatim copy of the
"OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf" library instance.
The new PciHostBridgeLibScan instance will ultimately duplicate a
negligible amount of code from the original, and will be used by the Bhyve
and OvmfXen platforms.
List the new driver in "Maintainers.txt", in the "OvmfPkg: bhyve-related
modules" and "OvmfPkg: Xen-related modules" sections.
This patch should be reviewed with "git show --find-copies-harder".
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-30-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe",
namely DriverInitialize()
[OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c],
bails out immediately if "PcdPciDisableBusEnumeration" is TRUE.
The Bhyve platform statically assigns this PCD TRUE. Thus, remove the
driver from the Bhyve platform.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-27-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe",
namely DriverInitialize()
[OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c],
bails out immediately if "PcdPciDisableBusEnumeration" is TRUE.
The OvmfXen platform statically assigns this PCD TRUE. Thus, remove the
driver from the OvmfXen platform.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-26-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:27 +0000 (22:14 +0200)]
OvmfPkg/Bhyve: make "PcdPciDisableBusEnumeration" Fixed-at-Build
The Bhyve platform specifies the dynamic access method for
"PcdPciDisableBusEnumeration" needlessly.
After the DSC file sets the PCD to TRUE by default, the PCD is never
written again. In particular, the
"OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf" file references the PCD
superfluously.
Make the PCD Fixed-At-Build, and remove the PCD reference from the INF
file.
(Note that further simplifications are possible in
"OvmfPkg/Bhyve/AcpiPlatformDxe", but those are out of scope for this patch
series.)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-25-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:26 +0000 (22:14 +0200)]
OvmfPkg: drop PcdPciDisableBusEnumeration from the AmdSev platform
With the Xen-dependent PcdSetBoolS() call removed from
OvmfPkg/PlatformPei, the "AmdSevX64.dsc" platform never writes
"PcdPciDisableBusEnumeration". This means we don't need a dynamic default
for the PCD in the DSC file; it could be declared Fixed-at-Build.
However, because the PCD's default value in "MdeModulePkg.dec" is FALSE,
remove the (same-value) platform default altogether.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-24-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:25 +0000 (22:14 +0200)]
OvmfPkg: drop PcdPciDisableBusEnumeration from the IA32, IA32X64, X64 DSCs
With the Xen-dependent PcdSetBoolS() call removed from
OvmfPkg/PlatformPei, the "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc",
"OvmfPkgX64.dsc" platforms never write "PcdPciDisableBusEnumeration". This
means we don't need a dynamic default for the PCD in the DSC files; it
could be declared Fixed-at-Build.
However, because the PCD's default value in "MdeModulePkg.dec" is FALSE,
remove the (same-value) platform defaults altogether.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-23-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Because "PcdPciDisableBusEnumeration" is always TRUE in the OvmfXen
platform, we can remove the delayed ACPI table installation from
XenAcpiPlatformDxe. A number of dependencies become useless this way;
remove them too.
(Note that, conversely, in the QemuFwCfgAcpiPlatformDxe driver, we
*cannot* assume that "PcdPciDisableBusEnumeration" is always FALSE,
regardless of Xen: in the ArmVirtQemu platform, the PCD may carry either
FALSE or TRUE, dependent on whether or not the QEMU "virt" machine
configuration includes a PCIe host controller, respectively.)
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-21-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:22 +0000 (22:14 +0200)]
OvmfPkg/OvmfXen: make "PcdPciDisableBusEnumeration" Fixed-at-Build
The OvmfXen platform specifies the dynamic access method for
"PcdPciDisableBusEnumeration" needlessly.
After the DSC file sets the PCD to TRUE by default, the InitializeXen()
function in XenPlatformPei superfluously sets the PCD to TRUE again. There
are no other writes to the PCD in the platform.
Make the PCD Fixed-At-Build, and remove the access (in fact, the whole
InitializeXen() function) from XenPlatformPei.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-20-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:20 +0000 (22:14 +0200)]
OvmfPkg/Bhyve/AcpiPlatformDxe: fix file path typo in comment
The built-in ACPI tables for Bhyve are located in the
"OvmfPkg/Bhyve/AcpiTables" module, not in the "OvmfPkg/AcpiTables" module.
Correct the typo in a code comment.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-18-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Xen is an advanced hypervisor; no Xen guest can function correctly without
the hypervisor's dynamically provided ACPI tables. Remove the built-in
(fallback) tables from XenAcpiPlatformDxe -- and the OvmfXen platform.
Remove any dependencies from XenAcpiPlatformDxe that are no longer needed.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-17-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The QemuDetected() function wraps QemuFwCfgIsAvailable(); it always fails
on Xen. Because of that, we can eliminate the QemuDetected() call itself
from the Xen ACPI platform driver, and then the rest of "Qemu.c" becomes
useless -- the workhorse function of that source file is
QemuInstallAcpiTable(), which we no longer call.
Remove any dependencies that are no longer needed by the
XenAcpiPlatformDxe driver.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-15-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:16 +0000 (22:14 +0200)]
OvmfPkg/XenAcpiPlatformDxe: remove the QEMU ACPI linker/loader client
The root of the QEMU ACPI linker/loader client in XenAcpiPlatformDxe is
the InstallQemuFwCfgTables() function. This function always fails on Xen,
due to its top-most QemuFwCfgFindFile() call.
Remove the InstallQemuFwCfgTables() function call from XenAcpiPlatformDxe,
along with all dependencies that now become unused.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-14-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:15 +0000 (22:14 +0200)]
OvmfPkg/AcpiPlatformDxe: remove the "AcpiPlatformDxe.inf" driver
The "OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" module is no longer
referenced in any platform DSC file; remove it.
That orphans the "AcpiPlatform.c", "Qemu.c" and "Xen.c" files in the
"OvmfPkg/AcpiPlatformDxe/" directory; remove them.
That in turn removes the only definitions of the InstallAcpiTable(),
QemuDetected(), QemuInstallAcpiTable(), InstallXenTables() functions in
the "OvmfPkg/AcpiPlatformDxe/" directory, so remove their declarations
from "AcpiPlatform.h".
Remove "OvmfPkg/AcpiPlatformDxe/Xen.c" from the "OvmfPkg: Xen-related
modules" section of "Maintainers.txt", as well.
Cc: Andrew Fish <afish@apple.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-13-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:14 +0000 (22:14 +0200)]
OvmfPkg/XenAcpiPlatformDxe: create from AcpiPlatformDxe
Create an almost verbatim copy of the
"OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" driver for the OvmfXen
platform. We're going to trim the driver in subsequent patches.
Ultimately, the XenAcpiPlatformDxe driver will duplicate a negligible
amount of code that is currently present in the QemuFwCfgAcpiPlatformDxe
driver.
List the new driver in "Maintainers.txt", in the "OvmfPkg: Xen-related
modules" section.
Switch the OvmfXen platform to the new driver at once.
This patch should be reviewed with "git show --find-copies-harder".
Cc: Andrew Fish <afish@apple.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-12-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:13 +0000 (22:14 +0200)]
OvmfPkg/AcpiPlatformDxe: consolidate #includes and [LibraryClasses]
- #include only such public headers in "AcpiPlatform.h" that are required
by the function declarations and type definitions introduced in
"AcpiPlatform.h". Don't use "AcpiPlatform.h" as a convenience #include
file.
- In every file, list every necessary public #include individually, with
an example identifier that's actually consumed.
Laszlo Ersek [Wed, 26 May 2021 20:14:12 +0000 (22:14 +0200)]
OvmfPkg/AcpiPlatformDxe: move "QemuLoader.h" to IndustryStandard
Turn the "QemuLoader.h" header into a public (IndustryStandard) one. The
QEMU ACPI linker-loader interface is stable between QEMU and multiple
guest firmwares.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-10-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:11 +0000 (22:14 +0200)]
OvmfPkg/AcpiPlatformDxe/QemuLoader.h: remove QemuFwCfgLib class dependency
"QemuLoader.h" needs the QEMU_FW_CFG_FNAME_SIZE macro. This macro used to
live in the QemuFwCfgLib class header, but we moved it to the more
foundational IndustryStandard include file called "QemuFwCfg.h" in commit 5583a8a4ffd0 ("OvmfPkg/QemuFwCfgLib: move types/macros from lib class to
IndustryStandard", 2017-02-22).
Replace the lib class dependency with the more basic IndustryStandard
dependency in "QemuLoader.h".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-9-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:08 +0000 (22:14 +0200)]
OvmfPkg/README: bump minimum QEMU version to 1.7.1, machine types to 1.7
Due to switching to the QemuFwCfgAcpiPlatformDxe driver earlier in this
series, require QEMU version 1.7.1 in the "OvmfPkg/README" file, and
require 1.7 or later machine types too.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:07 +0000 (22:14 +0200)]
OvmfPkg: switch the AmdSev platform to the fw_cfg-only ACPI platform driver
For consistency with the historical OvmfPkg* platforms, switch the
remotely attested, QEMU/KVM-only, AmdSev platform from the AcpiPlatformDxe
driver to the QemuFwCfgAcpiPlatformDxe driver.
No module remains dependent on XenPlatformLib, so remove the
XenPlatformLib class resolution too, from the DSC file.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:06 +0000 (22:14 +0200)]
OvmfPkg: switch IA32, IA32X64, X64 to the fw_cfg-only ACPI platform driver
Switch the historical OvmfPkg* platforms from the AcpiPlatformDxe driver
to the QemuFwCfgAcpiPlatformDxe driver. (The latter is used by the
ArmVirtQemu* platforms as well.)
The change effectively replaces the following call tree:
(1) Xen compatibility is removed from the ACPI platform driver of the
historical OvmfPkg* platforms.
(2) The ACPI tables that are statically built into OVMF (via
"OvmfPkg/AcpiTables/AcpiTables.inf") are never installed. In
particular, OVMF's own runtime preparation of the MADT and SSDT is
eliminated.
Because of (2), remove the "OvmfPkg/AcpiTables/AcpiTables.inf" module as
well -- and then the ACPITABLE build rule too.
Note that (2) only removes effectively dead code; the QEMU ACPI
linker-loader has taken priority since QEMU 1.7.1 (2014). References:
Laszlo Ersek [Wed, 26 May 2021 20:14:05 +0000 (22:14 +0200)]
OvmfPkg: remove the Xen drivers from the AmdSev platform
For symmetry with the historical OvmfPkg* platforms, remove the three Xen
drivers from the remotely attested, QEMU/KVM-only, AmdSev platform. Xen
(HVM and PVH) guests are supported by the dedicated OvmfXen platform.
No module remains dependent on XenHypercallLib, so remove the
XenHypercallLib class resolution too, from the DSC file.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 26 May 2021 20:14:04 +0000 (22:14 +0200)]
OvmfPkg: remove the Xen drivers from the IA32, IA32X64, and X64 platforms
Remove the three Xen drivers as the first step for removing Xen support
from the historical OvmfPkg* platforms. Xen (HVM and PVH) guests are
supported by the dedicated OvmfXen platform.
No module remains dependent on XenHypercallLib, so remove the
XenHypercallLib class resolutions too, from the DSC files.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Ni, Ray [Wed, 2 Jun 2021 08:11:45 +0000 (16:11 +0800)]
BaseTools: Change CLANG8ELF to CLANGDWARF
CLANGDWARF is more proper because it's similar to CLANGPDB that generates
PE images but with DWARF debug symbols.
This toolchain is needed for creating ELF format universal payload that
follows https://universalpayload.github.io/documentation/.
Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Liming Gao [Wed, 2 Jun 2021 08:11:43 +0000 (16:11 +0800)]
BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1603
LLVM/CLANG8 formal release http://releases.llvm.org/download.html#8.0.0
It can be downloaded and installed in Windows/Linux/Mac OS.
CLANG8ELF tool chain is added to generate ELF image, and convert to PE/COFF.
On Windows OS, set CLANG_HOST_BIN=n, set CLANG8_BIN=LLVM installed directory
For example:
set CLANG_HOST_BIN=n # use windows nmake
set CLANG8_BIN=C:\Program Files\LLVM\bin\
On Linux/Mac, set CLANG8_BIN=LLVM installed directory
This tool chain can be used to compile the firmware code. On windows OS,
Visual Studio is still required to compile BaseTools C tools and nmake.exe.
On Linux/Mac OS, gcc is used to compile BaseTools C tools. make is used
for makefile.
This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell.
This tool chain is verified in Windows/Linux and Mac OS.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
Liming Gao [Wed, 2 Jun 2021 08:11:41 +0000 (16:11 +0800)]
BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF image
CLANG8ELF tool chain generated ELF image with the different attributes
in section. Update GenFw to handle them.
1. .text section with writable attribute (support)
2. .reloc section has the symbol for *ABS* (skip)
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
Gerd Hoffmann [Wed, 2 Jun 2021 04:59:35 +0000 (06:59 +0200)]
OvmfPkg/VirtioMmioDeviceLib: Add EFIAPI to VirtioMmioSetQueueAddress
This error was found while compiling VirtioMmioDeviceLib for X64
with the GCC5 toolchain, where EFIAPI makes a difference.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210602045935.762211-1-kraxel@redhat.com>
[lersek@redhat.com: prepend module name to subject, trim subject back to
allowed length] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
A NameSeg is made 4 chars.
Cf. ACPI 6.4 s20.2.2 "Name Objects Encoding":
NameSeg := <leadnamechar namechar namechar namechar>
Notice that NameSegs shorter than 4 characters are filled
with trailing underscores (‘_’s).
AML_NAME_SEG_SIZE is currently defined in:
- DynamicTablesPkg/Library/Common/AmlLib/AmlDefines.h
- MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
Since the value can be inferred from the ACPI specification
and to avoid multiple definitions, move it to
MdePkg/Include/IndustryStandard/
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
According to xhci spec, at USB packet level, a Control Transfer
consists of multiple transactions partitioned into stages: a
setup stage, an optional data stage, and a terminating status
stage. If Data Stage does not exist, the Transfer Type flag(TRT)
should be No Data Stage.
So if data length equals to 0, TRT is set to 0.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
GetWakeupTime should return full time information, including
the daylight/timezone. Make use of the existing non-volatile
variables for that purpose. Moreover add an error checking
of possibly invalid parameters.
This partially fixes FWTS and SCT Set/GetWakeupTime tests on
Marvell platforms.
Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Marcin Wojtas [Sun, 23 May 2021 09:15:12 +0000 (17:15 +0800)]
MdePkg: Add new 16550-compatible Serial Port Subtypes to DBG2
The Microsoft Debug Port Table 2 (DBG2) specification revision
May 31, 2017 adds support for 16550-compatible Serial Port
Subtype with parameters defined in Generic Address Structure (GAS) [1]
Current Ppi/MmControl.h file has structure definition of "struct
_PEI_MM_CONTROL_PPI". This name mismatches with its definition in PI
Specification v1.7 (Errata) as "struct _EFI_PEI_MM_CONTROL_PPI".
In addition, field types "PEI_MM_ACTIVATE" and "PEI_MM_DEACTIVATE" used
in "struct _PEI_MM_CONTROL_PPI" mismatches with the definition of
"EFI_PEI_MM_ACTIVATE" and "EFI_PEI_MM_DEACTIVATE" in the PI spec.
This change fixes these mismatches by using the PI spec defined names.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Fixes: 6f33f7a262314af35e2b99c849e08928ea49aa55 Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
IntelFsp2WrapperPkg defines following PCDs:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdFlashMicrocodeOffset
But the PCD name caused confusion because UefiCpuPkg defines:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdCpuMicrocodePatchAddress in IntelFsp2WrapperPkg means the base
address of the FV that holds the microcode.
PcdCpuMicrocodePatchAddress in UefiCpuPkg means the address of the
microcode.
The relationship between the PCDs is:
IntelFsp2WrapperPkg.PcdCpuMicrocodePatchAddress
+ IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset
== UefiCpuPkg.PcdCpuMicrocodePatchAddress
To avoid confusion and actually the PCDs in IntelFsp2WrapperPkg
are only used by a sample FSP-T wrapper, this patch removes
the 3 PCDs defined in IntelFsp2WrapperPkg.
The FSP-T wrapper is updated to directly use the ones in UefiCpuPkg.
Signed-off-by: Jason Lou <yun.lou@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
The Flush parameter is used to provide a hint whether the specified range
is Mmio address. Now that we have a dedicated helper to clear the
memory encryption mask for the Mmio address range, its safe to remove the
Flush parameter from MemEncryptSev{Set,Clear}PageEncMask().
Since the address specified in the MemEncryptSev{Set,Clear}PageEncMask()
points to a system RAM, thus a cache flush is required during the
encryption mask update.
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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Message-Id: <20210519181949.6574-14-brijesh.singh@amd.com>
The MemEncryptSevClearMmioPageEncMask() helper can be used for clearing
the memory encryption mask for the Mmio region.
The MemEncryptSevClearMmioPageEncMask() is a simplified version of
MemEncryptSevClearPageEncMask() -- it does not flush the caches after
clearing the page encryption mask.
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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Message-Id: <20210519181949.6574-10-brijesh.singh@amd.com>
The PVALIDATE instruction validates or rescinds validation of a guest
page RMP entry. Upon completion, a return code is stored in EAX, rFLAGS
bits OF, ZF, AF, PF and SF are set based on this return code. If the
instruction completed succesfully, the rFLAGS bit CF indicates if the
contents of the RMP entry were changed or not.
For more information about the instruction see AMD APM volume 3.
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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Message-Id: <20210519181949.6574-8-brijesh.singh@amd.com>
Version 2 of GHCB introduces NAE for creating AP when SEV-SNP is enabled
in the guest VM. See the GHCB specification, Table 5 "List of Supported
Non-Automatic Events" and sections 4.1.9 and 4.3.2, for further details.
While at it, define the VMSA state save area that is required for creating
the AP. The save area format is defined in AMD APM volume 2, Table B-4
(there is a mistake in the table that defines the size of the reserved
area at offset 0xc8 as a dword, when it is actually a word). The format of
the save area segment registers is further defined in AMD APM volume 2,
sections 10 and 15.5.
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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Message-Id: <20210519181949.6574-7-brijesh.singh@amd.com>
[lersek@redhat.com: fix typo in BZ reference]
The Page State Change NAE exit will be used by the SEV-SNP guest to
request a page state change using the GHCB protocol. See the GHCB
spec section 4.1.6 and 2.3.1 for more detail on the structure
definitions.
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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Erdem Aktas <erdemaktas@google.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Message-Id: <20210519181949.6574-6-brijesh.singh@amd.com>
Version 2 of the GHCB spec introduces several new SNP-specific NAEs.
Unfortunately, the names for those NAEs break the alignment. Add some
white spaces so that the SNP support patches do not break the alignment.
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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Message-Id: <20210519181949.6574-3-brijesh.singh@amd.com>
The SEV-ES stacks currently share a page with the reset code and data.
Separate the SEV-ES stacks from the reset vector code and data to avoid
possible stack overflows from overwriting the code and/or data.
When SEV-ES is enabled, invoke the GetWakeupBuffer() routine a second time
to allocate a new area, below the reset vector and data.
Both the PEI and DXE versions of GetWakeupBuffer() are changed so that
when PcdSevEsIsEnabled is true, they will track the previous reset buffer
allocation in order to ensure that the new buffer allocation is below the
previous allocation. When PcdSevEsIsEnabled is false, the original logic
is followed.
Fixes: 7b7508ad784d16a5208c8d12dff43aef6df0835b Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Marvin Häuser <mhaeuser@posteo.de> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <3cae2ac836884b131725866264e0a0e1897052de.1621024125.git.thomas.lendacky@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
The GICv3 architecture supports up to 1020 ordinary interrupt
lines. The actual number of interrupts supported is described by the
ITLinesNumber field in the GICD_TYPER register. The total number of
implemented registers is normally calculated as
32*(ITLinesNumber+1). However, maximum value (0x1f) is a special case
since that would indicate that 1024 interrupts are implemented.
Add handling for this special case in ArmGicGetMaxNumInterrupts.
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Signed-off-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Laszlo Ersek [Fri, 21 May 2021 20:40:37 +0000 (22:40 +0200)]
MdeModulePkg/VariableLock: downgrade compatibility warnings to DEBUG_WARN
Commit a18a9bde36d2 ("MdeModulePkg/Variable/RuntimeDxe: Restore Variable
Lock Protocol behavior", 2020-12-15), for bug 3111, added two such sets of
debug messages that:
(a) are relevant for developers,
(b) yet should not necessarily poke end-users, because no functionality
suffers in practice.
Both message sets are in function VariableLockRequestToLock(): the first
is a generic interface deprecation warning; the second is the
double-locking situation, which we permit for compatibility (return status
EFI_SUCCESS).
Both message sets should be emitted with the DEBUG_WARN mask, not the most
serious DEBUG_ERROR mask. On some platforms, the serial console carries
both terminal traffic, and grave (DEBUG_ERROR-only) log messages. On such
platforms, both message sets may be perceived as a nuisance by end-users,
as there is nothing they can do, and there's nothing they *should* do --
in practice, nothing malfunctions.
(Such a platform is ArmVirtQemu, built with "-D
DEBUG_PRINT_ERROR_LEVEL=0x80000000".)
Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3410 Fixes: a18a9bde36d2ffc12df29cdced1efa1f8f9f2021 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210521204037.11980-1-lersek@redhat.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Sergei Dmitrouk [Tue, 18 May 2021 16:09:42 +0000 (00:09 +0800)]
CryptoPkg/BaseCryptLib: Fix possible uninitialized use
`Result` can be used uninitialized in both functions after following
either first or second `goto` statement.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Guomin Jiang <guomin.jiang@intel.com> Signed-off-by: Sergei Dmitrouk <sergei@posteo.net> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Sergei Dmitrouk [Tue, 18 May 2021 16:09:41 +0000 (00:09 +0800)]
MdeModulePkg/PciBusDxe: Fix possible uninitialized use
If the function gets invalid value for the `ResizableBarOp` parameter
and asserts are disabled, `Bit` can be used uninitialized.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Sergei Dmitrouk <sergei@posteo.net> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Currently, UefiBootManagerLib has the below assumption:
Assume the BootManagerMenuFile is in the same FV as the module links to this library.
It has some limitation now, so remove the assumption.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
5-level paging can be enabled on CPU which supports up to 52 physical
address size. But when the feature was enabled, the 48 address size
limit was not removed and the 5-level paging testing didn't access
address >= 2^48. So the issue wasn't detected until recently an
address >= 2^48 is accessed.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
This patch fixes the issue observed during
BSF file to YAML file conversion. It also
addresses the issue during multibyte array
data conversion check, for example the data
representation of 0xFFFF instead of 0xFF, 0xFF
would be thrown exception "Array size is not
proper" without this patch.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Signed-off-by: Loo Tung Lun <tung.lun.loo@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Currenly, when using the Brotli tool to compress data, the output
compressed binary file does not record complete compressed data
when size of input file is too large, which makes the data loss and
will trigger decompress-check issue.
The Brotli document mentioned:
The brotli tool use BrotliEncoderCompressStream method to compresses
input stream to output stream. Under some circumstances (e.g. lack of
output stream capacity) the BrotliEncoderOperation would require
several calls to BrotliEncoderCompressStream. The method must be
called again until both input stream is depleted and encoder has no
more output after the method is called.
This patch fixes this issue based on the Brotli document.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Rebecca Cran [Wed, 5 May 2021 15:04:55 +0000 (23:04 +0800)]
MdeModulePkg: Fix various typos
Fix various typos throughout MdeModulePkg.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
An update to expand the mExceptionNameStr array failed to add a comma
after original last entry, therefore causing the #CP name to have extra
incorrect characters and the remaining entries to be indexed incorrectly
(off by 1).
Add a comma after the "#CP" entry to resolve this issue.
Fixes: 5277540e37e88a1a69f9517c4ad895051b4b3ed3 Cc: Allen Wynn <Allen_Wynn@Dell.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <40e55bf6563ed8ea4962a1219efbe1ab77a56cc4.1620919615.git.thomas.lendacky@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BaseTools: Add support for version 3 of FMP Image Header structure
Add support for the ImageCapsuleSupport field, introduced in version 3
of the EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER structure. This
structure member is used to indicate if the corresponding payload has
support for authentication and dependency.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
A VS2012 build fails with a cast conversion warning when the SEV-ES work
area PCD is cast as a pointer to the SEV_ES_AP_JMP_FAR type.
When casting from a PCD value to a pointer, the cast should first be done
to a UINTN and then to the pointer. Update the code to perform a cast to
a UINTN before casting to a pointer to the SEV_ES_AP_JMP_FAR type.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Fixes: 7b7508ad784d16a5208c8d12dff43aef6df0835b Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <c89bc819856d448360430c32cb3833a9667f987b.1620656694.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Rebecca Cran [Mon, 10 May 2021 21:53:07 +0000 (15:53 -0600)]
MdePkg/BaseRngLib: Add support for ARMv8.5 RNG instructions
Make BaseRngLib more generic by moving x86-specific functionality into
'Rand' and adding files under 'AArch64' to support the optional ARMv8.5
RNG instruction RNDR that is a part of FEAT_RNG.
If the DSC file provides an override of a Guided tool path
and/or Guided tool GUID value, then make sure the one from the
DSC file is used if it is higher priority than the Guided tool
in the tools_def.txt file. This makes the Guided tool used by
GenFds match the tool listed GuidedSectionTools.txt.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
UnitTestFrameworkPkg: Sample unit test hangs when running in OVMF/QEMU
Sample unit tests in UnitTestFrameworkPkg hangs when running in OVMF/QEMU
environment. Build target is X64/GCC5. Fixing this issue by adding EFIAPI
to ReportPrint() function that use VA_ARGS.
Signed-off-by: Getnat Ejigu <getnatejigu@gmail.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* Save/Restore global state in GetToolChainAndFamilyFromDsc()
This resolves an issue where the multi-arch build for
UefiPayloadPkg would skip the autogen and build of IA32
components.
* Expand tools wildcard.
This resolves the issue where autogen makefile contents
would have a BUIDLRULEFAMILY tools definitions with an
'*' in the tool field that breaks the build from invalid
makefile syntax.
* Build rule family higher priority than Family.
This resolves the issue where flags were appended from
both the BUILDRULEFAMILY and FAMILY when only
BUILDRULEFAMILY should be appended when present.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Steven Shi <steven.shi@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Andrew Fish <afish@apple.com>
The OVMF Tcg2Config PEIM adds the gOvmfTpmMmioAccessiblePpiGuid as a
Depex for IA32 and X64 builds so that the MMIO range is properly mapped
as unencrypted for an SEV-ES guest before the Tcg2Config PEIM is loaded.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <d6538e6c557173d260e272a0e5659683175e2e06.1619716333.git.thomas.lendacky@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
During PEI, the MMIO range for the TPM is marked as encrypted when running
as an SEV guest. While this isn't an issue for an SEV guest because of
the way the nested page fault is handled, it does result in an SEV-ES
guest terminating because of a mitigation check in the #VC handler to
prevent MMIO to an encrypted address. For an SEV-ES guest, this range
must be marked as unencrypted.
Create a new x86 PEIM for TPM support that will map the TPM MMIO range as
unencrypted when SEV-ES is active. The gOvmfTpmMmioAccessiblePpiGuid PPI
will be unconditionally installed before exiting. The PEIM will exit with
the EFI_ABORTED status so that the PEIM does not stay resident. This new
PEIM will depend on the installation of the permanent PEI RAM, by
PlatformPei, so that in case page table splitting is required during the
clearing of the encryption bit, the new page table(s) will be allocated
from permanent PEI RAM.
Update all OVMF Ia32 and X64 build packages to include this new PEIM.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <42794cec1f9d5bc24cbfb9dcdbe5e281ef259ef5.1619716333.git.thomas.lendacky@amd.com>
[lersek@redhat.com: refresh subject line] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Lendacky, Thomas [Thu, 29 Apr 2021 17:12:12 +0000 (12:12 -0500)]
OvmfPkg: Define a new PPI GUID to signal TPM MMIO accessability
Define a new PPI GUID that is to be used as a signal of when it is safe
to access the TPM MMIO range. This is needed so that, when SEV is active,
the MMIO range can be mapped unencrypted before it is accessed.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <03e292339273721724c8b14605cfe9d7bbe45a71.1619716333.git.thomas.lendacky@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Enabling TPM support results in guest termination of an SEV-ES guest
because it uses MMIO opcodes that are not currently supported.
Add support for the new MMIO opcodes (0xA0 - 0xA3), MOV instructions which
use a memory offset directly encoded in the instruction. Also, add a DEBUG
statement to identify an unsupported MMIO opcode being used.
Fixes: c45f678a1ea2080344e125dc55b14e4b9f98483d Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <2fdde57707b52ae39c49341c9d97053aaff56e4a.1619716333.git.thomas.lendacky@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
The MOVZX and MOVSX instructions use the ModRM byte in the instruction,
but the instruction decoding support was not decoding it. This resulted
in invalid decoding and failing of the MMIO operation. Also, when
performing the zero-extend or sign-extend operation, the memory operation
should be using the size, and not the size enumeration value.
Add the ModRM byte decoding for the MOVZX and MOVSX opcodes and use the
true data size to perform the extend operations. Additionally, add a
DEBUG statement identifying the MMIO address being flagged as encrypted
during the MMIO address validation.
Fixes: c45f678a1ea2080344e125dc55b14e4b9f98483d Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <5949d54cb2c9ab69256f67ed5654b32654c0501c.1619716333.git.thomas.lendacky@amd.com>
Update BaseTools to support new build targets, new tool chains,
and new architectures declared in DSC file [BuildOptions] sections.
* Do not expand * when tools_def.txt is parsed. Only expand when
both tools_def.txt and DSC [BuilsOptions] sections have been parsed.
This also requires more flexible matching of tool keys that contain *
in tool key fields.
* Pre-scan the platform DSC file for FAMILY and TOOLCHAIN declarations
DSC in [BuildOptions] sections before the FAMILY and TOOLCHAIN need
to be known.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Michael D Kinney [Wed, 28 Apr 2021 20:53:55 +0000 (13:53 -0700)]
EmulatorPkg: Temp remove IA32 GCC CI builds
EmulatorPkg IA32 GCC builds are not working due to a failure
to install the i386 library dependencies in Ubuntu 18.04.
Temporarily disable these specific CI tests until the issue
can be resolved.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
projects / mirror_edk2.git / log