Zhiguang Liu [Fri, 30 Apr 2021 06:14:33 +0000 (14:14 +0800)]
MdeModulePkg: Add new structure for the Universal Payload ACPI Table Hob
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
From SysTableInfo Hob, get Smbios table address, and create
gUniversalPayloadSmbiosTableGuid Hob to store it. Remove directly adding
smbios table to ConfigurationTable.
Dxe module SmbiosDxe will parse it and install smbios table from it.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Zhiguang Liu [Fri, 30 Apr 2021 05:36:54 +0000 (13:36 +0800)]
MdeModulePkg/Universal/SmbiosDxe: Scan for existing tables
The default EfiSmbiosProtocol operates on an empty SMBIOS table.
The SMBIOS tables are provided by the bootloader on UefiPayloadPkg.
Scan for existing tables in SmbiosDxe and load them if they seem valid.
This fixes the settings menu not showing any hardware information, instead
only "0 MB RAM" was displayed.
Tests showed that the OS can still see the SMBIOS tables.
SmbiosDxe will get the SMBIOS from a guid Hob.
Also will keep the SmbiosHandle if it is available.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Zhiguang Liu [Fri, 30 Apr 2021 05:35:04 +0000 (13:35 +0800)]
MdeModulePkg: Add new structure for the Universal Payload SMBios Table Hob
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Zhiguang Liu [Fri, 30 Apr 2021 05:09:39 +0000 (13:09 +0800)]
UefiPayloadPkg: UefiPayload retrieve PCI root bridge from Guid Hob
UefiPayload parse gUniversalPayloadPciRootBridgeInfoGuid Guid Hob to
retrieve PCI root bridges information.
gUniversalPayloadPciRootBridgeInfoGuid Guid Hob should be created by
Bootloader.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Zhiguang Liu [Fri, 30 Apr 2021 05:07:32 +0000 (13:07 +0800)]
MdeModulePkg: Add new structure for the PCI Root Bridge Info Hob
Also add ExceptionList in MdeModulePkg\MdeModulePkg.ci.yaml, to avoid open
CI issue, because UID and HID are terms which are already used in current
source code.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Zhiguang Liu [Fri, 30 Apr 2021 04:44:10 +0000 (12:44 +0800)]
MdeModulePkg: Add Universal Payload general definition header file
Add Universal Payload general definition header file according to
Universal Payload's documentation as below:
https://universalpayload.github.io/documentation/
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Zhiguang Liu [Thu, 10 Jun 2021 01:49:17 +0000 (09:49 +0800)]
UefiPayloadPkg: Get platform specific logic via protocol for BDS
Currently, BDS driver will link a PlatformBootManagerLib, which contains
platform specific logic. This patch get the platform specific logic from
a protocol, so that platform logic for Boot manager can be in another
binary.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The value of SupportedAttributes in OpalGetSupportedAttributesInfo ()
is left undetermined, if the caller doesn't initialize it.
Initialize it in the function entry.
Signed-off-by: Scottie Kuo <scottie.kuo@intel.com> Cc: Qi Zhang <qi1.zhang@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Maggie Chu <maggie.chu@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Jian J Wang <jian.j.wang@intel.com>
When the boot manager menu is from different FV, the current logic still
use the device path of the FV as the module links to this library
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: Ray Ni <ray.ni@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Existing implementation could modify class global data that causes
potential incorrect file mask to be used for execution of plugin.
This change switches class variable to be tuple so that it cannot be
accidently modified. Local usage of STANDARD_PLUGIN_DEFINED_PATHS is also
changed to copy to new list before modification.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
IScsiDxe (that is, the initiator) receives two hex-encoded strings from
the iSCSI target:
- CHAP_C, where the target challenges the initiator,
- CHAP_R, where the target answers the challenge from the initiator (in
case the initiator wants mutual authentication).
Accordingly, we have two IScsiHexToBin() call sites:
- At the CHAP_C decoding site, check whether the decoding succeeds. The
decoded buffer ("AuthData->InChallenge") can accommodate 1024 bytes,
which is a permissible restriction on the target, per
<https://tools.ietf.org/html/rfc7143#section-12.1.3>. Shorter challenges
from the target are acceptable.
- At the CHAP_R decoding site, enforce that the decoding both succeed, and
provide exactly ISCSI_CHAP_RSP_LEN bytes. CHAP_R contains the digest
calculated by the target, therefore it must be of fixed size. We may
only call IScsiCHAPAuthTarget() if "TargetRsp" has been fully populated.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-11-lersek@redhat.com>
The IScsiHexToBin() function documents the EFI_BUFFER_TOO_SMALL return
condition, but never actually checks whether the decoded buffer fits into
the caller-provided room (i.e., the input value of "BinLength"), and
EFI_BUFFER_TOO_SMALL is never returned. The decoding of "HexStr" can
overflow "BinBuffer".
This is remotely exploitable, as shown in a subsequent patch, which adds
error checking to the IScsiHexToBin() call sites. This issue allows the
target to compromise the initiator.
Introduce EFI_BAD_BUFFER_SIZE, in addition to the existent
EFI_BUFFER_TOO_SMALL, for reporting a special case of the buffer overflow,
plus actually catch the buffer overflow.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-10-lersek@redhat.com>
The IScsiHexToBin() function has the following parser issues:
(1) If the *subject sequence* in "HexStr" is empty, the function returns
EFI_SUCCESS (with "BinLength" set to 0 on output). Such inputs should
be rejected.
(2) The function mis-handles a "HexStr" that ends with a stray nibble. For
example, if "HexStr" is "0xABC", the function decodes it to the bytes
{0xAB, 0x0C}, sets "BinLength" to 2 on output, and returns
EFI_SUCCESS. Such inputs should be rejected.
(3) If an invalid hex char is found in "HexStr", the function treats it as
end-of-hex-string, and returns EFI_SUCCESS. Such inputs should be
rejected.
All of the above cases are remotely triggerable, as shown in a subsequent
patch, which adds error checking to the IScsiHexToBin() call sites. While
the initiator is not immediately compromised, incorrectly parsing CHAP_R
from the target, in case of mutual authentication, is not great.
Extend the interface contract of IScsiHexToBin() with
EFI_INVALID_PARAMETER, for reporting issues (1) through (3), and implement
the new checks.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-9-lersek@redhat.com>
Laszlo Ersek [Tue, 8 Jun 2021 12:12:56 +0000 (14:12 +0200)]
NetworkPkg/IScsiDxe: reformat IScsiHexToBin() leading comment block
We'll need further return values for IScsiHexToBin() in a subsequent
patch; make room for them in the leading comment block of the function.
While at it, rewrap the comment block to 80 characters width.
No functional changes.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-8-lersek@redhat.com>
Laszlo Ersek [Tue, 8 Jun 2021 12:12:55 +0000 (14:12 +0200)]
NetworkPkg/IScsiDxe: assert that IScsiBinToHex() always succeeds
IScsiBinToHex() is called for encoding:
- the answer to the target's challenge; that is, CHAP_R;
- the challenge for the target, in case mutual authentication is enabled;
that is, CHAP_C.
The initiator controls the size of both blobs, the sizes of their hex
encodings are correctly calculated in "RspLen" and "ChallengeLen".
Therefore the IScsiBinToHex() calls never fail; assert that.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-7-lersek@redhat.com>
The first one may wrap under zero, the latter two may wrap over
MAX_UINT32.
Rewrite the calculation using SafeIntLib.
While at it, change the type of the "Index" variable from UINTN to UINT32.
The largest "Index"-based value that we calculate is
Index * 2 + 2 (with (Index == BinLength))
Because the patch makes
BinLength * 2 + 3
safe to calculate in UINT32, using UINT32 for
Index * 2 + 2 (with (Index == BinLength))
is safe too. Consistently using UINT32 improves readability.
This patch is best reviewed with "git show -W".
The integer overflows that this patch fixes are theoretical; a subsequent
patch in the series will audit the IScsiBinToHex() call sites, and show
that none of them can fail.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-6-lersek@redhat.com>
Laszlo Ersek [Tue, 8 Jun 2021 12:12:53 +0000 (14:12 +0200)]
NetworkPkg/IScsiDxe: clean up library class dependencies
Sort the library class dependencies in the #include directives and in the
INF file. Remove the DpcLib class from the #include directives -- it is
not listed in the INF file, and IScsiDxe doesn't call either DpcLib API
(QueueDpc(), DispatchDpc()). No functional changes.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-5-lersek@redhat.com>
Laszlo Ersek [Tue, 8 Jun 2021 12:12:52 +0000 (14:12 +0200)]
NetworkPkg/IScsiDxe: clean up "ISCSI_CHAP_AUTH_DATA.OutChallengeLength"
The "ISCSI_CHAP_AUTH_DATA.OutChallenge" field is declared as a UINT8 array
with ISCSI_CHAP_AUTH_MAX_LEN (1024) elements. However, when the challenge
is generated and formatted, only ISCSI_CHAP_RSP_LEN (16) octets are used
in the array.
Change the array size to ISCSI_CHAP_RSP_LEN, and remove the (now unused)
ISCSI_CHAP_AUTH_MAX_LEN macro.
Remove the "ISCSI_CHAP_AUTH_DATA.OutChallengeLength" field, which is
superfluous too.
Most importantly, explain in a new comment *why* tying the challenge size
to the digest size (ISCSI_CHAP_RSP_LEN) has always made sense. (See also
Linux kernel commit 19f5f88ed779, "scsi: target: iscsi: tie the challenge
length to the hash digest size", 2019-11-06.) For sure, the motivation
that the new comment now explains has always been there, and has always
been the same, for IScsiDxe; it's just that now we spell it out too.
No change in peer-visible behavior.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-4-lersek@redhat.com>
The ISCSI_CHAP_AUTH_MAX_LEN macro is defined with value 1024.
The usage of this macro currently involves a semantic (not functional)
bug, which we're going to fix in a subsequent patch, eliminating
ISCSI_CHAP_AUTH_MAX_LEN altogether.
For now, remove the macro's usage from all
"ISCSI_CHAP_AUTH_DATA.InChallenge" contexts. This is doable without
duplicating open-coded constants.
No changes in functionality.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-3-lersek@redhat.com>
Laszlo Ersek [Wed, 9 Jun 2021 15:57:31 +0000 (17:57 +0200)]
OvmfPkg/PlatformCI: bump QEMU choco package version to 2021.5.5
We currently require QEMU choco package version 2020.08.14 (from commit 3ab9d60fcbe7), in "OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml".
Said package version references the following URLs:
In theory, the old QEMU choco packages should be fixed (their powershell
scripts should be updated to reference the new URLs on Stefan Weil's
website). However, this PlatformCI issue is blocking the merging of the
security fix for TianoCore#3356, so getting PlatformCI functional again is
urgent. Let's bump our QEMU choco package requirement to 2021.5.5, whose
URLs work, for now.
(Currently we cannot use any other choco package version, as Stefan's
directories <https://qemu.weilnetz.de/w32> and
<https://qemu.weilnetz.de/w64>, without any further subdirectories, only
offer the 20210505 EXE files.)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Jordan Justen <jordan.l.justen@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> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210609155731.10431-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
Liming Gao [Sat, 5 Jun 2021 01:17:46 +0000 (09:17 +0800)]
BaseTools GenFw: Fix regression issue to convert the image to ACPI data
Commit c6b872c updates GenFw base code attribute to find .text section.
With GCC49 tool chain, aslc file is compiled into elf image.
But, its text section has no CODE attribute. So, it can't be detected
by new GenFw tool.For this type file. its text section is not required.
Its data section will be converted to acpi table.
This fix is to remove assert check when the generated image is ACPI data.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Tested-by: Leif Lindholm <leif@nuviainc.com>
The Xen customizations are very light-weight in this
PlatformBootManagerLib instance. Isolating them statically, for the sake
of the first three DSC files, would save negligible binary code size, and
would likely worsen code complexity (by way of introducing new internal
interfaces) or blow up source code size (by duplicating almost the entire
lib instance source code). So for now, keep this one bit of Xen dynamism
even on QEMU.
However, because it's only PlatformBootManagerLib now that uses
XenPlatformLib (for the above-stated enlightenment), restrict the
XenPlatformLib class resolution in the first three DSC files to the only
DXE driver that consumes PlatformBootManagerLib (and therefore
XenPlatformLib): BdsDxe. This will cause a build failure later if someone
attempts to call a XenPlatformLib API (that is, tries to re-introduce Xen
enlightenment) in a different module in these non-Xen 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-44-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:45 +0000 (22:14 +0200)]
OvmfPkg/SmbiosPlatformDxe: split Xen entry point from QEMU entry point
Remove the SmbiosTablePublishEntry() function from "SmbiosPlatformDxe.c".
"SmbiosPlatformDxe.c" becomes hypervisor-agnostic.
Add SmbiosTablePublishEntry() back, simplified for QEMU, to the existent
file "Qemu.c". The GetQemuSmbiosTables() function no longer needs to be
declared in "SmbiosPlatformDxe.h"; "SmbiosPlatformDxe.h" becomes
hypervisor-agnostic.
Add SmbiosTablePublishEntry() back, renamed and simplified for Xen, to the
new, arch-independent file "Xen.c". (The existent Xen-specific C files are
arch-dependent.)
Update both INF files; remove the dependencies that are now superfluous in
each.
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-43-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
"OvmfPkg/SmbiosPlatformDxe" is structured somewhat differently from the
drivers duplicated and trimmed thus far in this series. The final QEMU and
Xen versions will share a relatively significant amount of code, therefore
duplicating the whole driver is less useful, even temporarily. Instead,
duplicate the INF file, in preparation for customizing the entry point
function.
Because ArmVirtXen doesn't actually include OvmfPkg/SmbiosPlatformDxe [*],
there is only one platform that's supposed to consume the new driver:
OvmfXen. Switch OvmfXen to the new driver at once.
[*] See commit 164cf4038357 ("OvmfPkg: SmbiosPlatformDxe: restrict current
Xen code to IA32/X64", 2015-07-26).
This patch is best viewed 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: 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-42-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:43 +0000 (22:14 +0200)]
OvmfPkg/SmbiosPlatformDxe: declare InstallAllStructures() in header file
Add an extern declaration for the InstallAllStructures() function to the
"SmbiosPlatformDxe.h" header file. (The leading comment block and the
prototype are simply copied from "SmbiosPlatformDxe.c".)
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-41-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:42 +0000 (22:14 +0200)]
OvmfPkg/SmbiosPlatformDxe: split GetXenSmbiosTables() decl. to new header
Move the declaration of the GetXenSmbiosTables() function to a new header
file called "XenSmbiosPlatformDxe.h". (The only declaration that remains
in "SmbiosPlatformDxe.h" for now is that of GetQemuSmbiosTables().)
Modify the pattern in "Maintainers.txt" so that the new file be covered in
the "OvmfPkg: Xen-related modules" section.
This patch is best viewed with "git show --no-renames".
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-40-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:41 +0000 (22:14 +0200)]
OvmfPkg/SmbiosPlatformDxe: locate SMBIOS protocol in InstallAllStructures()
Locate the SMBIOS protocol internally to the InstallAllStructures()
function. This has no performance impact (InstallAllStructures() is only
called once), but moving the code from the entry point function makes the
latter smaller. And that will be useful when we split the entry point
function to two versions.
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-39-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:40 +0000 (22:14 +0200)]
OvmfPkg/SmbiosPlatformDxe: return EFI_NOT_FOUND if there is no SMBIOS data
According to the function-top comment, SmbiosTablePublishEntry() is
supposed to return an error code if no SMBIOS data is found, from either
GetXenSmbiosTables() or GetQemuSmbiosTables(). Currently the function
returns EFI_SUCCESS in this case however (propagated from
gBS->LocateProtocol()). Make the return code match the documentation.
(This issue is not too important, but it gets in the way of splitting the
entry point function next.)
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-38-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:39 +0000 (22:14 +0200)]
OvmfPkg/SmbiosPlatformDxe: clean up #includes and INF
- Sort all sections in the INF file.
- Remove unused packages (MdeModulePkg) and lib classes (BaseMemoryLib)
from the INF file.
- Restrict some lib classes (BaseLib, HobLib) and GUIDs (gEfiXenInfoGuid)
to IA32 and X64, in the INF file; only the IA32/X64 Xen implementation
requires these.
- Don't make "SmbiosPlatformDxe.h" #include everything just as a
convenience. Spell out directly needed #includes in every file (annotate
each with an example identifier consumed), drop unused #includes.
- Keep #includes sorted.
- Remove the leading underscore from the #include guard macro name in
"SmbiosPlatformDxe.h".
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-37-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:36 +0000 (22:14 +0200)]
OvmfPkg/PciHostBridgeLibScan: remove QEMU (fw_cfg) support
The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
instance is used in the following platforms in edk2:
OvmfPkg/Bhyve/BhyveX64.dsc
OvmfPkg/OvmfXen.dsc
Both platforms define "PcdPciDisableBusEnumeration" with Fixed-at-Build
access method, and TRUE value. Remove the PCD from the
PciHostBridgeLibScan instance, and everything else that is useful only
when the PCD is FALSE.
In practice, this removes the PciHostBridgeUtilityGetRootBridges()
function call, which is based on fw-cfg; see
"OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c".
(Note that the dependency on PciHostBridgeUtilityLib remains in place,
given that the PciHostBridgeLibScan instance continues using lower-level
functions from the library that do not depend on fw-cfg.)
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-34-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
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>
projects / mirror_edk2.git / log