summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-06-04OvmfPkg/XenAcpiPlatformDxe: remove OVMF's built-in ACPI tablesLaszlo Ersek4-212/+0
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>
2021-06-04OvmfPkg/XenAcpiPlatformDxe: remove the InstallAcpiTable() helper functionLaszlo Ersek3-63/+36
The InstallAcpiTable() helper function buys us nothing. Reduce code complexity by removing the function. This patch is best viewed with "git show -b". 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-16-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-06-04OvmfPkg/XenAcpiPlatformDxe: remove QEMU fw_cfg dependencyLaszlo Ersek4-542/+1
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>
2021-06-04OvmfPkg/XenAcpiPlatformDxe: remove the QEMU ACPI linker/loader clientLaszlo Ersek6-1717/+1
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>
2021-06-04OvmfPkg/AcpiPlatformDxe: remove the "AcpiPlatformDxe.inf" driverLaszlo Ersek6-1193/+0
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>
2021-06-04OvmfPkg/XenAcpiPlatformDxe: create from AcpiPlatformDxeLaszlo Ersek12-2/+3024
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>
2021-06-04OvmfPkg/AcpiPlatformDxe: consolidate #includes and [LibraryClasses]Laszlo Ersek10-33/+41
- #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. - Remove unnecessary lib classes, add unlisted lib classes. - Remove unnecessary #include directives, add unlisted #include directives. 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-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-06-04OvmfPkg/AcpiPlatformDxe: move "QemuLoader.h" to IndustryStandardLaszlo Ersek4-3/+1
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>
2021-06-04OvmfPkg/AcpiPlatformDxe/QemuLoader.h: remove QemuFwCfgLib class dependencyLaszlo Ersek1-1/+1
"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>
2021-06-04OvmfPkg/AcpiPlatformDxe: sort #includes and [LibraryClasses]Laszlo Ersek7-31/+31
Place all public #includes first, all module-private #includes second. Separate them with a single empty line. Keep each section sorted in itself. Sort all sections in both INF 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-8-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-06-04OvmfPkg/AcpiPlatformDxe: fix header file wartsLaszlo Ersek2-6/+6
- Remove the leading underscores from the #include guard macro names; clean up the names in general. - Remove the useless "Include/" directory prefix from the public header pathnames. - Fix incorrect file-top comment. 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-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-06-04OvmfPkg/README: bump minimum QEMU version to 1.7.1, machine types to 1.7Laszlo Ersek1-35/+8
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>
2021-06-04OvmfPkg: switch the AmdSev platform to the fw_cfg-only ACPI platform driverLaszlo Ersek2-11/+2
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>
2021-06-04OvmfPkg: switch IA32, IA32X64, X64 to the fw_cfg-only ACPI platform driverLaszlo Ersek6-30/+6
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: InstallAcpiTables [AcpiPlatform.c] XenDetected [XenPlatformLib] * InstallXenTables [Xen.c] * GetXenAcpiRsdp [Xen.c] * InstallQemuFwCfgTables [QemuFwCfgAcpi.c] ... InstallOvmfFvTables [AcpiPlatform.c] * QemuDetected [Qemu.c] * LocateFvInstanceWithTables [AcpiPlatform.c] * QemuInstallAcpiTable [Qemu.c] * QemuInstallAcpiMadtTable [Qemu.c] * CountBits16 [Qemu.c] * QemuInstallAcpiSsdtTable [Qemu.c] * GetSuspendStates [Qemu.c] * PopulateFwData [Qemu.c] * with the one below: InstallAcpiTables [QemuFwCfgAcpiPlatform.c] InstallQemuFwCfgTables [QemuFwCfgAcpi.c] ... eliminating the sub-trees highlighted with "*". There are two consequences: (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: - https://wiki.qemu.org/Planning/1.7 - https://wiki.qemu.org/Features/ACPITableGeneration - edk2 commit 96bbdbc85693 ("OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMU", 2014-03-31) - edk2 commit 387536e472aa ("OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface", 2014-09-22) 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-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-06-04OvmfPkg: remove the Xen drivers from the AmdSev platformLaszlo Ersek2-7/+0
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>
2021-06-04OvmfPkg: remove the Xen drivers from the IA32, IA32X64, and X64 platformsLaszlo Ersek6-21/+0
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>
2021-06-04BaseTools: Change CLANG8ELF to CLANGDWARFNi, Ray1-90/+91
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>
2021-06-04BaseTools: Update ClangBase.lds to keep dynamic sectionNi, Ray1-3/+2
The .dynamic section is needed for ELF runtime relocation. 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>
2021-06-04BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8Liming Gao1-0/+102
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>
2021-06-04BaseTools: Update build_rule to skip CLANG resource section generationLiming Gao1-3/+2
LLVM/CLANG doesn't support resource section generation when ELF image generated. Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
2021-06-04BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF imageLiming Gao2-11/+6
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>
2021-06-04BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-sizeLiming Gao1-0/+79
LLVM LLD linker doesn't support common-page-size option. So, max-page-size is used. To not impact GCC tool chain, new ClangBase.lds is added. Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
2021-06-04MdePkg/BaseLib: Fix AsmReadSs() with GCC toolchainSatoshi Tanda2-2/+2
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3405 AsmReadSs() in Ia32/GccInlinePriv.c and X64/GccInlinePriv.c return the DS segment selector value instead of SS. Signed-off-by: Satoshi Tanda <tanda.sat@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2021-06-02OvmfPkg/VirtioMmioDeviceLib: Add EFIAPI to VirtioMmioSetQueueAddressGerd Hoffmann2-0/+2
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>
2021-06-02DynamicTablesPkg: Use AML_NAME_SEG_SIZE definePierre Gondois3-12/+5
Use the newly introduced defined value in: MdePkg/Include/IndustryStandard/AcpiAml.h Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
2021-06-02MdePkg/MdeModulePkg: Move AML_NAME_SEG_SIZE definitionPierre Gondois2-2/+6
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>
2021-06-02MdeModulePkg/Xhci: Fix TRT when data length is 0Wenyi Xie2-8/+18
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3418 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>
2021-06-02EmbeddedPkg/RealTimeClockRuntimeDxe: Improve GetWakeupTimeMarcin Wojtas1-0/+11
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>
2021-06-01MdePkg: Update DBG2 and SPCR header with NVIDIA 16550 SubtypeAshish Singhal2-0/+6
Add macros for NVIDIA 16550 UART specific debug port subtype in both DBG2 as well as SPCR header file. Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sunny Wang <sunny.wang@arm.com>
2021-06-01MdePkg: Add new 16550-compatible Serial Port Subtypes to DBG2Marcin Wojtas2-0/+6
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] Reflect that in the EDK2 headers. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sunny Wang <sunny.wang@arm.com>
2021-06-01MdePkg: MmControl: Fix function and structure definition mismatchesKun Qin1-4/+4
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3397 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>
2021-05-31IntelFsp2WrapperPkg: Remove microcode related PCDsLou, Yun3-14/+7
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3334 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 IntelFsp2WrapperPkg.PcdCpuMicrocodePatchRegionSize - IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset == UefiCpuPkg.PcdCpuMicrocodePatchRegionSize 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>
2021-05-29OvmfPkg/BaseMemEncryptSevLib: remove Flush parameterBrijesh Singh10-62/+21
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 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>
2021-05-29OvmfPkg/TpmMmioSevDecryptPei: use MemEncryptSevClearMmioPageEncMask()Brijesh Singh1-3/+2
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Use the MemEncryptSevClearMmioPageEncMask() to clear memory encryption mask for the Mmio address range. 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-13-brijesh.singh@amd.com>
2021-05-29OvmfPkg/QemuFlashFvbServicesRuntimeDxe: use Mmio helper to clear enc maskBrijesh Singh2-6/+4
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Use the MemEncryptSevClearMmioPageEncMask() to clear memory encryption mask for the Mmio address range. 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-12-brijesh.singh@amd.com>
2021-05-29OvmfPkg/AmdSevDxe: use MemEncryptSevClearMmioPageEncMask() to clear EncMaskBrijesh Singh1-6/+4
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Use the MemEncryptSevClearMmioPageEncMask() to clear memory encryption mask for the Mmio and NonExistent address range. 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-11-brijesh.singh@amd.com>
2021-05-29OvmfPkg/BaseMemEncryptSevLib: introduce MemEncryptSevClearMmioPageEncMask()Brijesh Singh6-0/+175
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 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>
2021-05-29MdePkg/BaseLib: add support for RMPADJUST instructionTom Lendacky4-0/+84
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The RMPADJUST instruction will be used by the SEV-SNP guest to modify the RMP permissions for a guest page. See AMD APM volume 3 for further details. 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: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Message-Id: <20210519181949.6574-9-brijesh.singh@amd.com>
2021-05-29MdePkg/BaseLib: add support for PVALIDATE instructionBrijesh Singh4-0/+101
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 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>
2021-05-29MdePkg/Register/Amd: define GHCB macros for SNP AP creationTom Lendacky1-0/+84
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 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]
2021-05-29MdePkg/Register/Amd: define GHCB macro for the Page State ChangeBrijesh Singh2-0/+48
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 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>
2021-05-29MdePkg/Register/Amd: define GHCB macro for Register GPA structureBrijesh Singh1-0/+7
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 An SEV-SNP guest is required to perform the GHCB GPA registration. See the GHCB specification for further details. 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-5-brijesh.singh@amd.com>
2021-05-29MdePkg/Register/Amd: define GHCB macros for hypervisor feature detectionBrijesh Singh2-0/+15
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Version 2 of GHCB introduces advertisement of features that are supported by the hypervisor. See the GHCB spec section 2.2 for an additional details. 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-4-brijesh.singh@amd.com>
2021-05-29MdePkg/Register/Amd: realign macros with more space for future expansionBrijesh Singh2-11/+11
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 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>
2021-05-29MdePkg/Register/Amd: expand the SEV MSR to include the SNP definitionBrijesh Singh1-1/+6
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Define the SEV-SNP MSR bits. 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-2-brijesh.singh@amd.com>
2021-05-29UefiCpuPkg/MpInitLib: Allocate a separate SEV-ES AP reset stack areaLendacky, Thomas3-18/+69
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3324 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>
2021-05-29Maintainers.txt: add Sami Mujawar as top-level ArmVirtPkg reviewerLaszlo Ersek1-10/+1
For distributing ArmVirtPkg patch review tasks better, move Sami Mujawar from the "ArmVirtPkg: Kvmtool" section to the top-level "ArmVirtPkg" section. Given that "ArmVirtPkg: Kvmtool" remains without a specific "R" role, remove "ArmVirtPkg: Kvmtool" altogether. Cc: Andrew Fish <afish@apple.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> 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> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210514114857.12286-1-lersek@redhat.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
2021-05-27ArmPkg/ArmGic: Fix maximum number of interrupts in GICv3edk2-stable202105Andreas Sandberg1-2/+9
Bugzilla: 3415 (https://bugzilla.tianocore.org/show_bug.cgi?id=3415) 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>
2021-05-23MdeModulePkg/VariableLock: downgrade compatibility warnings to DEBUG_WARNLaszlo Ersek1-5/+5
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>
2021-05-21MdeModulePkg/PlatformDriOverrideDxe: Fix overflow condition checkLi, Walon1-1/+1
Code mistake, VariableIndex is smaller normally than buffer+buffersize so should not break loop. Signed-off-by: Walon Li <walon.li@hpe.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>