Laszlo Ersek [Tue, 29 Jun 2021 16:33:32 +0000 (18:33 +0200)]
NetworkPkg/IScsiDxe: re-set session-level authentication state before login
RFC 7143 explains that a single iSCSI session may use multiple TCP
connections. The first connection established is called the leading
connection. The login performed on the leading connection is called the
leading login. Before the session is considered full-featured, the leading
login must succeed. Further (non-leading) connections can be associated
with the session later.
(It's unclear to me from RFC 7143 whether the non-leading connections
require individual (non-leading) logins as well, but that particular
question is irrelevant from the perspective of this patch; see below.)
The data model in IScsiDxe exhibits some confusion, regarding connection /
session association:
- On one hand, the "ISCSI_SESSION.Conns" field is a *set* (it has type
LIST_ENTRY), and accordingly, connections can be added to, and removed
from, a session, with the IScsiAttatchConnection() and
IScsiDetatchConnection() functions.
- On the other hand, ISCSI_MAX_CONNS_PER_SESSION has value 1, therefore no
session will ever use more than 1 connection at a time (refer to
instances of "Session->MaxConnections" in
"NetworkPkg/IScsiDxe/IScsiProto.c").
This one-to-many confusion between ISCSI_SESSION and ISCSI_CONNECTION is
very visible in the CHAP logic, where the progress of the authentication
is maintained *per connection*, in the "ISCSI_CONNECTION.AuthStep" field
(with values such as ISCSI_AUTH_INITIAL, ISCSI_CHAP_STEP_ONE, etc), but
the *data* for the authentication are maintained *per session*, in the
"AuthType" and "AuthData" fields of ISCSI_SESSION. Clearly, this makes no
sense if multiple connections are eligible for logging in.
Knowing that IScsiDxe uses only one connection per session (put
differently: knowing that any connection is a leading connection, and any
login is a leading login), there is no functionality bug. But the data
model is still broken: "AuthType", "AuthData", and "AuthStep" should be
maintained at the *same* level -- be it "session-level" or "(leading)
connection-level".
Fixing this data model bug is more than what I'm signing up for. However,
I do need to add one function, in preparation for multi-hash support:
whenever a new login is attempted (put differently: whenever the leading
login is re-attempted), which always happens with a fresh connection, the
session-level authentication data needs to be rewound to a sane initial
state.
Introduce the IScsiSessionResetAuthData() function. Call it from the
central -- session-level -- IScsiSessionLogin() function, just before the
latter calls the -- connection-level -- IScsiConnLogin() function.
Right now, do nothing in IScsiSessionResetAuthData(); so functionally
speaking, the patch is a no-op.
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=3355 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: <20210629163337.14120-2-lersek@redhat.com>
Ray Ni [Tue, 29 Jun 2021 03:07:51 +0000 (11:07 +0800)]
UefiPayloadPkg/PayloadLoader: Remove assertion
For R_386_RELATIVE and R_X86_64_RELATIVE, today's logic assumes that
the content pointed by the Rela->r_offset is 0 but it's not always
TRUE. We observed that linker may set the content to Rela->r_addend.
The patch removes the assertion.
There is no functionality impact for this patch.
Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
Ray Ni [Tue, 29 Jun 2021 02:43:58 +0000 (10:43 +0800)]
UefiPayloadPkg/PayloadLoader: Fix bug in locating relocation section
Per ELF spec, the DT_REL/DT_RELA tag in dynamic section stores the
virtual address of the relocation section.
But today's code logic treats it as the section offset and finds
the relocation section whose offset equals to DT_REL/DT_RELA.
The logic can work when the section offset equals to the section
virtual address. But when the ELF is generated from the link script
that reserves a sizeof(pe_header) in the file beginning, the section
offset doesn't equal to section virtual address. Such logic can
not find the relocation section.
The patch fixes this bug.
Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
This is a GUI interface that can be used by users who
would like to change configuration settings directly
from the interface without having to modify the source.
This tool depends on Python GUI tool kit Tkinter.
It runs on both Windows and Linux.
The user needs to load the YAML file along with DLT file
for a specific board into the ConfigEditor, change the desired
configuration values. Finally, generate a new configuration delta
file or a config binary blob for the newly changed values to take
effect. These will be the inputs to the merge tool or the stitch
tool so that new config changes can be merged and stitched into
the final configuration blob.
This tool also supports binary update directly and display FSP
information. It is also backward compatible for BSF file format.
Co-authored-by: Maurice Ma <maurice.ma@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Signed-off-by: Loo Tung Lun <tung.lun.loo@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
MdePkg : Add IPMI Macro and Structure Defintions to resolve build errors
Build error reported for missing structures IPMI_SET_BOOT_OPTIONS_RESPONSE,
EFI_IPMI_MSG_GET_BMC_EXEC_RSP, macro EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FULL_RUNTIME/EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE
when using edk2-platforms\Features\Intel\OutOfBandManagement\IpmiFeaturePkg
Rename EFI_IPMI_MSG_GET_BMC_EXEC_RSPB,
EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to
IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE
Unfortunately, Xen isn't ready to deal with mapping at the top of the
physical address space, so we relocate the mapping after the LAPIC
location.
See this thread about the issue with the mapping:
- https://lore.kernel.org/xen-devel/f8c4151a-6dac-d87c-ef46-eb35ada07bd9@suse.com/
The PhysicalAddressIdentityMapping() call isn't going to do anything
anymore since everything under 4GB is already mapped, but there is no
need to remove the call.
Cc: Jan Beulich <JBeulich@suse.com> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20210628132337.46345-1-anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: replace "CC:" with "Cc:", to pacify PatchCheck.py]
Dov Murik [Mon, 28 Jun 2021 10:51:09 +0000 (10:51 +0000)]
OvmfPkg/GenericQemuLoadImageLib: Read cmdline from QemuKernelLoaderFs
Remove the QemuFwCfgLib interface used to read the QEMU cmdline
(-append argument) and the initrd size. Instead, use the synthetic
filesystem QemuKernelLoaderFs which has three files: "kernel", "initrd",
and "cmdline".
Note that besides re-exposing the kernel command line as a file in the
synthetic filesystem, we also revert back to AllocatePool instead of
AllocatePages.
Dov Murik [Mon, 28 Jun 2021 10:51:07 +0000 (10:51 +0000)]
OvmfPkg/X86QemuLoadImageLib: plug cmdline blob leak on success
When QemuLoadKernelImage() ends successfully, the command-line blob is
not freed, even though it is not used elsewhere (its content is already
copied to KernelLoadedImage->LoadOptions). The memory leak bug was
introduced in commit 7c47d89003a6 ("OvmfPkg: implement QEMU loader
library for X86 with legacy fallback", 2020-03-05).
Dov Murik [Mon, 28 Jun 2021 10:51:06 +0000 (10:51 +0000)]
OvmfPkg/GenericQemuLoadImageLib: plug cmdline blob leak on success
When QemuLoadKernelImage() ends successfully, the command-line blob is
not freed, even though it is not used elsewhere (its content is already
copied to KernelLoadedImage->LoadOptions). The memory leak bug was
introduced in commit ddd2be6b0026 ("OvmfPkg: provide a generic
implementation of QemuLoadImageLib", 2020-03-05).
MM Configuration PPI was defined in PI Specification since v1.5. This
change added definition of such PPI and related GUIDs into MdePkg.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The definition of EFI_MM_RESERVED_MMRAM_REGION, according to PI Spec 1.5
is also referenced in EFI_PEI_MM_CONFIGURATION_PPI. Defining this
structure as is will enforce any potential usage of MM Configuration PPI
interface to include <Protocol/MmConfiguration.h>.
This change moves this structure definition to PiMultiPhase.h, which is
already included by Protocol/MmConfiguration.h through PiMmCis.h. It also
paves way for introducing Ppi/MmConfiguration.h with proper dependency.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
This patch adds support for R_RISCV_CALL_PLT and R_RISCV_GOT_HI20
relocations generated by PIE enabled compiler. This also needed
changes to R_RISCV_32 and R_RISCV_64 relocations as explained in
https://github.com/riscv/riscv-gnu-toolchain/issues/905#issuecomment-846682710
Testing:
1) Debian GCC 8.3.0 and booted sifive_u and QMEU virt models.
2) Debian 10.2.0 and booted QEMU virt model.
3) riscv-gnu-tool chain 9.2 and booted QEMU virt model.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Abner Chang <abner.chang@hpe.com> Reviewed-by: Daniel Schaefer <daniel.schaefer@hpe.com> Tested-by: Daniel Schaefer <daniel.schaefer@hpe.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Rebecca Cran [Sun, 13 Jun 2021 03:43:01 +0000 (11:43 +0800)]
BaseTools: Reset ERRORLEVEL in toolsetup.bat after edk2basetools check
When using the in-source BaseTools, edksetup.bat will exit with an
ERRORLEVEL of 1 because the line in toolsetup.bat
"%PYTHON_COMMAND% -c "import edk2basetools" >NUL 2>NUL"
fails.
Ensure ERRORLEVEL is set to 0 when edksetup.bat or toolsetup.bat is
successfully run.
Rebecca Cran [Sun, 13 Jun 2021 03:35:06 +0000 (11:35 +0800)]
BaseTools: Remove check for Split.exe in toolset.bat
Split is now a Python tool, so BaseTools\Bin\Win32\Split.exe no longer
exists. Remove the check for it from toolsetup.bat to prevent the
erroneous claim that the binary C tools are missing.
duntan [Mon, 21 Jun 2021 08:23:28 +0000 (16:23 +0800)]
UefiPayloadPkg: consume the BootManagerMenuFile HOB
Consume the BootManagerMenuFile HOB in PlatformBootManagerLib
This Lib is in UefiPayloadPkg
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: DunTan <dun.tan@intel.com>
duntan [Mon, 21 Jun 2021 07:29:40 +0000 (15:29 +0800)]
UefiPayloadPkg: Add new structure for BootManagerMenuFile HOB
Add new structure for BootManagerMenuFile HOB in UefiPayloadPkg
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: DunTan <dun.tan@intel.com>
Zhiguang Liu [Thu, 17 Jun 2021 16:42:41 +0000 (00:42 +0800)]
UefiPayloadPkg: Add PcdResetOnMemoryTypeInformationChange in UefiPayloadPkg
This PCD will be consumed by Universal Payload
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>
Zhiguang Liu [Thu, 17 Jun 2021 16:39:33 +0000 (00:39 +0800)]
UefiPayloadPkg: Add PcdInstallAcpiSdtProtocol feature in UefiPayloadPkg
To install ACPI SDT protocol, define PcdInstallAcpiSdtProtocol as TRUE.
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>
Zhiguang Liu [Thu, 17 Jun 2021 02:09:34 +0000 (10:09 +0800)]
UefiPayloadPkg: Add macro to enable and disable some drivers
Add macro EMU_VARIABLE_ENABLE and DISABLE_RESET_SYSTEM to include
or exclude some drivers from Payload
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>
Zhiguang Liu [Thu, 17 Jun 2021 01:20:57 +0000 (09:20 +0800)]
UefiPayloadPkg: Remove assert when reserve MMIO/IO resource for devices
Some boot loader may already reserve MMIO/IO resource for IOAPIC and HPET,
so remove the assert when reserve MMIO/IO resource for IOAPIC and HPET
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>
Zhiguang Liu [Wed, 16 Jun 2021 14:52:23 +0000 (22:52 +0800)]
UefiPayloadPkg: Include UniversalPayLoad modules in UefiPayloadPkg.dsc
Add a new macro "UNIVERSAL_PAYLOAD" to build Universal Payload.
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>
Zhiguang Liu [Thu, 10 Jun 2021 07:08:13 +0000 (15:08 +0800)]
UefiPayloadPkg: Fix up UPL Pcd database
Edk2 bootloader will pass the pei pcd database, and UPL also contain a
PCD database.
Dxe PCD driver has the assumption that the two PCD database can be
catenated and the local token number should be successive。
This patch will manually fix up the UPL PCD database to meet that
assumption.
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>
Zhiguang Liu [Fri, 7 May 2021 07:41:59 +0000 (15:41 +0800)]
UefiPayloadPkg: Get and enter DxeCore for Universal Payload
From gUniversalPayloadExtraDataGuid Guid Hob, get the Dxe FV information,
and get the Dxe Core from the FV.
Also, make sure if there are muliple FV hob, the FV hob pointing to this FV
will be the first in the hob list.
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>
Zhiguang Liu [Fri, 7 May 2021 07:28:31 +0000 (15:28 +0800)]
UefiPayloadPkg: Create separate Payload Entry for UniversalPayload
This patch create the UniversalPayload Entry based on the UefiPayload
Entry. It implements the logic to find a proper memory range to create the
new Hob and migrate the Hobs from Bootloader.
To make the change history clear, the logic to get the DxeCore will be in
the next patch.
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>
Zhiguang Liu [Sun, 25 Apr 2021 07:50:46 +0000 (15:50 +0800)]
UefiPayloadPkg: Update the function definition of HobConstructor
Update the function defination of HobConstructor to align the Phit Hob
structure.
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>
Zhiguang Liu [Sun, 20 Jun 2021 15:30:07 +0000 (23:30 +0800)]
UefiPayloadPkg: Add a separate PlatformHookLib for Universal Payload
Add a new separate PlatformHookLib for Universal Payload to consume Guid
Hob gUniversalPayloadSerialPortInfoGuid to get serial port information
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>
Zhiguang Liu [Fri, 7 May 2021 05:49:24 +0000 (13:49 +0800)]
MdeModulePkg: Add new structure for the Universal Payload Serial Port Info
Add Universal Payload Serial Port Info definition header file according to
Universal Payload's documentation as below:
https://universalpayload.github.io/documentation/
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> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Zhiguang Liu [Fri, 7 May 2021 05:34:20 +0000 (13:34 +0800)]
UefiPayloadPkg: Add HobLib for UniversalPayload
For payload entry, use PayloadEntryHobLib as HobLib and payload entry
should initialize hob base.
For DxeCore, use new added DxeHobLib as HobLib, and DxeCore will
initialize hob base.
For Dxe Driver, use new added DxeHobLib as HobLib, and use DxeHobListLib
to initialize hob base.
Adding a new library DxeHobLib + DxeHobListLib instead of using the
DxeHobLib.inf in MdePkg is because the constructor needed be separated
from DxeHobLib.
If not, when building UefiPayloadPkg, the dependency chain is as below:
DebugLib -> SerialPortLib -> PlatformHookLib -> HobLib -> DebugLib
Each library has a constructor, and this becomes a constructor circle.
To break the circle, separate the constructor from the HobLib as a new
DxeHobListLib, which won't depend on DebugLib.
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: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
xueshengfeng [Tue, 8 Jun 2021 04:30:44 +0000 (12:30 +0800)]
CryptoPkg/BaseCryptLib: Enabled CryptSha512 for Smm/Runtime drivers
Intel Platform utility Syscfg/sysfwupdt will trigger SMI
to enter BIOS interface. then BIOS invoke EncodePassword
in SMM mode to check password.
it's need sha384(in CryptSha512.c) in SMM mode.
the origin SmmCryptLib.lib size is 1389KB,
after changed, the size is 1391KB.
the origin RuntimeCryptLib.lib size is 911KB,
after changed,the size is 913KB.
in SmmCryptLib.inf and RuntimeCryptLib.inf,
change CryptSha512NULL.c to CryptSha512.c.
Per update from Cspell tool, the minimal requirement of Cspell 5.x
regarding Node is 12 and above. This has caused multple Cspell failures
during CI build validation:
"Failed to process "**.c" TypeError: text.matchAll(...) is not a function
or its return value is not iterable"
This change updates the lowest required node version to 14.x to support
Cspell functionalities.
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: Kun Qin <kuqin12@gmail.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Currently several DXE crash due to invalid memory resource settings.
The PciHostBridgeDxe which expects the MMCONF and PCI Aperature
to be EfiMemoryMappedIO, but currently those regions are (partly)
mapped as EfiReservedMemoryType.
coreboot and slimbootloader provide an e820 compatible memory map,
which doesn't work well with EDK2 as the e820 spec is missing MMIO regions.
In e820 'reserved' could either mean "DRAM used by boot firmware" or "MMIO
in use and not detectable by OS".
Guess Top of lower usable DRAM (TOLUD) by walking the bootloader provided
memory ranges. Memory types of RAM, ACPI and ACPI NVS below 4 GiB are used
to increment TOLUD and reserved memory ranges touching TOLUD at the base
are also assumed to be reserved DRAM, which increment TOLUD.
Then mark everything reserved below TOLUD as EfiReservedMemoryType and
everything reserved above TOLUD as EfiMemoryMappedIO.
This fixes assertions seen in PciHostBridgeDxe.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com>
Sami Mujawar [Tue, 15 Jun 2021 15:21:27 +0000 (16:21 +0100)]
ArmVirtPkg: Add PCIe host bridge utility lib for ArmVirtPkg
PCIe support has been added to Kvmtool Virtual Machine Manager.
The PCI host bridge utility lib is used to retrieve information
about the Root Bridges in a platform.
Therefore, add an instance of PciHostBridgeUtilityLib as this is
required to enable PCIe support for Kvmtool firmware.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Processor location information check needs to updated
When Core 0 is disabled.
In C1e.c, change MSR_FEATURE_CONFIG to MSR_NEHALEM_POWER_CTL in comments
to match the correct MSR name.
Signed-off-by: Daoxiang Li <daoxiang.li@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
Rebecca Cran [Mon, 14 Jun 2021 18:57:49 +0000 (12:57 -0600)]
ArmPkg: Move cache defs used in Universal/Smbios into ArmCache.h
Many of the cache definitions in ArmLibPrivate.h are being used outside
of ArmLib, in Universal/Smbios. Move them into ArmCache.h to make them
public, and remove the include of ArmLibPrivate.h from files in
Universal/Smbios.
Long times spent on shadowing oprom from graphics card to system memory.
We are currently using 8 bit read cycles. This needs to be wider,
at least 32bit reads to reduce the time for oprom shadow.
Signed-off-by: Sumana Venur <sumana.venur@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Spellcheck was not covering all specified files due to CSpell v5 and
Node v10 incompatibility of current CI pipeline configuration.
This change switches the spellcheck for ArmPlatformPkg to AuditOnly to
avoid potentially numerous spell errors. The correction action is to be
revisited by package maintainers once the tool incompatibility is
resolved.
Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
gaoliming [Wed, 16 Jun 2021 07:58:09 +0000 (15:58 +0800)]
BaseTools GenFw: Keep read only alloc section as text when convert ELF
This is the fix of the regression issue at c6b872c6.
Based on ELF spec, readonly alloc section is .rodata section. It is used.
This fix is to add back original check logic for ELF section. Now,
the readonly alloc section and execute alloc section are regarded as .text.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Ray Ni [Sat, 1 May 2021 10:42:36 +0000 (18:42 +0800)]
PeiCore: Remove assertion when failing to load PE image
EFI_PEI_LOAD_FILE_PPI is invoked by DxeIpl for loading DxeCore.
It's possible that the instance produced by PeiCore fails to load but
other instances of EFI_PEI_LOAD_FILE_PPI can load.
Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn>
Ray Ni [Sat, 1 May 2021 12:24:55 +0000 (20:24 +0800)]
UefiPayloadPkg: Add PayloadLoaderPeim which can load ELF payload
Per universal payload spec, the payload is in ELF format.
The patch adds a payload loader that supports to load ELF image.
The location of extra data sections whose names start with "upld."
is stored in UNIVERSAL_PAYLOAD_EXTRA_DATA HOB.
Signed-off-by: Maurice Ma <maurice.ma@intel.com> Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
Ray Ni [Sat, 1 May 2021 12:17:45 +0000 (20:17 +0800)]
MdeModulePkg/UniversalPayload: Add definition for extra info in payload
The payload is in ELF format per the universal payload spec.
UNIVERSAL_PAYLOAD_INFO_HEADER is stored in the ELF payload as a separate
section named ".upld_info".
Extra data needed by payload is stored in sections whose name starts
with ".upld.".
Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Guo Dong <guo.dong@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Zhiguang Liu [Wed, 2 Jun 2021 14:30:08 +0000 (22:30 +0800)]
UefiPayloadPkg: Use DynamicEx instead of Dynamic to pass PCD across binary
When passing PCD database from Edk2 boot loader to Universal Payload, the
local token number in boot loader PCD database can be different with that
in Payload PCD database.
Dynamic PCD directly use local token number, while DynamicEx will search
token number by Guid and ExTokenNumber, which are unique pair and can make
sure finding the correct token number in boot loader's PCD database.
Therefore, using DynamicEx instead of Dynamic.
Also, explicitly define some PCDs as DynamicEx, or their default type will
be Dynamic
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>
From SysTableInfo Hob, get ACPI table address, and create
gUniversalPayloadAcpiTableGuid Hob to store it.
Remove directly adding ACPI table to ConfigurationTable.
Dxe ACPI driver will parse it and install ACPI table from Guid Hob.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Cc: Ray Ni <ray.ni@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 06:17:56 +0000 (14:17 +0800)]
MdeModulePkg/ACPI: Install ACPI table from HOB.
If HOB contains APCI table information, entry point of AcpiTableDxe.inf
should parse the APCI table from HOB, and install these tables.
We assume the whole ACPI table
(starting with EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
is contained by a single gEfiAcpiTableGuid HOB.
If error happens when installing ACPI table, stop installing and removing
all the tables that are already added.
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: Liming Gao <gaoliming@byosoft.com.cn> Cc: Ray Ni <ray.ni@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 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>
projects / mirror_edk2.git / log