LegacyBiosDxe is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code [*] [**]:
- GUIDs (protocols or otherwise):
- gEfiIsaIoProtocolGuid
- gEfiLegacy8259ProtocolGuid
- gEfiLegacyBiosGuid
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Guid/LegacyBios.h
- Protocol/IsaIo.h
- Protocol/Legacy8259.h
- Protocol/LegacyBios.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
- PCDs:
- PcdEbdaReservedMemorySize
- PcdEndOpromShadowAddress
- PcdHighPmmMemorySize
- PcdLegacyBiosCacheLegacyRegion
- PcdLowPmmMemorySize
- PcdOpromReservedMemoryBase
- PcdOpromReservedMemorySize
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiIsaIoProtocolGuid
- gEfiLegacy8259ProtocolGuid
- gEfiLegacyBiosGuid
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Guid/LegacyBios.h
- Protocol/IsaIo.h
- Protocol/Legacy8259.h
- Protocol/LegacyBios.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
- PCDs:
- PcdEbdaReservedMemorySize
- PcdEndOpromShadowAddress
- PcdHighPmmMemorySize
- PcdLegacyBiosCacheLegacyRegion
- PcdLowPmmMemorySize
- PcdOpromReservedMemoryBase
- PcdOpromReservedMemorySize
[*] Note that gEfiGenericMemTestProtocolGuid, while not a CSM-related
protocol, also becomes useless in the OVMF platforms, so we'll deal with
that later in the series as well.
[**] Note that gEfiLegacyRegion2ProtocolGuid, while a CSM-related
protocol, cannot be scheduled for removal, because the protocol GUID is
defined in "MdePkg.dec", and it's not only "OvmfPkg/Csm/CsmSupportLib"
that produces it in all of edk2, but also
"MdeModulePkg/Universal/LegacyRegion2Dxe" (not used by OVMF). For the same
reason, the "Protocol/LegacyRegion2.h" header (from MdePkg) cannot be
scheduled for removal.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-16-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The UEFI protocol database cannot contain gEfiLegacyBiosProtocolGuid any
longer, after excluding LegacyBiosDxe from the OVMF platforms. Therefore,
instruct PciBusDxe from IncompatiblePciDeviceSupportDxe to allocate 64-bit
BARs above 4 GB regardless of a CSM.
Regression test: in commit 855743f717 ("OvmfPkg: prevent 64-bit MMIO BAR
degradation if there is no CSM", 2016-05-25), where we introduced
IncompatiblePciDeviceSupportDxe, we said, "By default, the PCI Bus driver
considers an option ROM reason enough for allocating the 64-bit MMIO BARs
in 32-bit address space". Therefore it suffices to verify the 64-bit BARs
of a device for which QEMU provides an option ROM. The simplest case is
the virtio-net-pci device. And indeed, with this patch applied, the log
contains:
> PciBus: Discovered PCI @ [04|00|00] [VID = 0x1AF4, DID = 0x1041]
> BAR[1]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset = 0x14
> BAR[4]: Type = PMem64; Alignment = 0x3FFF; Length = 0x4000; Offset = 0x20
This portion shows that Bus|Device|Function 04|00|00 is a (modern)
virito-net-pci device [VID = 0x1AF4, DID = 0x1041].
> PciBus: Resource Map for Bridge [00|01|03]
> Type = Mem32; Base = 0x81200000; Length = 0x200000; Alignment = 0x1FFFFF
> Base = Padding; Length = 0x200000; Alignment = 0x1FFFFF
> Base = 0x81200000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [04|00|00:14]
> Type = Mem32; Base = 0x81A43000; Length = 0x1000; Alignment = 0xFFF
> Type = PMem64; Base = 0x800200000; Length = 0x100000; Alignment = 0xFFFFF
> Base = 0x800200000; Length = 0x4000; Alignment = 0x3FFF; Owner = PCI [04|00|00:20]
This quote shows that 04|00|00 has a BAR at 0x8_0020_0000.
(It also shows that the device is behind a bridge (PCIe root port) whose
own BDF is 00|01|03.)
> [Security] 3rd party image[7CEEB418] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/Offset(0x10E00,0x273FF).
> None of Tcg2Protocol/CcMeasurementProtocol is installed.
> InstallProtocolInterface: [EfiLoadedImageProtocol] 7D2E5140
> Loading driver at 0x0007CA9F000 EntryPoint=0x0007CAA5447 1af41000.efi
> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7D5B2198
And this part finally shows that the iPXE option ROM for the device
(1af41000.efi) was detected and is loaded. (Same PCIe root port, and PCIe
root ports can only host a single device.)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-14-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The CSM-based VideoDxe driver is a special UEFI_DRIVER module that both
follows and doesn't follow the UEFI driver model.
Namely, in the Supported and Start members of its Driver Binding Protocol
instance, it consumes the Legacy Bios Protocol directly from the UEFI
protocol database, as opposed to (only) opening protocols on the handle
that it is supposed to bind.
Furthermore, the driver "marks" its own image handle with the
NULL-interface "Legacy Bios" (pseudo-protocol) GUID, in order to "inform
back" the provider of the Legacy Bios Protocol, i.e., LegacyBiosDxe, that
VideoDxe is a "BIOS Thunk Driver" in the system.
Quoting "OvmfPkg/Csm/Include/Guid/LegacyBios.h", such a driver follows the
UEFI Driver Model, but still uses the Int86() or FarCall() services of the
Legacy Bios Protocol as the basis for the UEFI protocol it produces.
In a sense, there is a circular dependency between VideoDxe and
LegacyBiosDxe; each knows about the other. However, VideoDxe is a
UEFI_DRIVER, while LegacyBiosDxe is a platform DXE_DRIVER with a very long
DEPEX. Therefore, for keeping dependencies conceptually intact, first
exclude VideoDxe from the OVMF platforms. Always include the
hypervisor-specific real UEFI video driver.
--*--
Note that the pathname
"IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf" in the bhyve
platform DSC and FDF files is bogus anyway.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Corvin Köhne <corvink@freebsd.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-9-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
LegacyBootMaintUiLib is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-7-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
LegacyBootManagerLib is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-5-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
OS may enable CET-IBT feature by set MSR IA32_U_CET.bit2.
If IA32_U_CET.bit2 is set, CPU is in WAIT_FOR_ENDBRANCH state and
the next assemble code is not ENDBR, it will trigger #CP exception
when set CR4.CET bit.
SMI handler needs to backup MSR IA32_U_CET and clear MSR IA32_U_CET
before set CR4.CET bit,
And SMI handler needs to restore MSR IA32_U_CET when exit SMI handler.
Signed-off-by: Sheng Wei <w.sheng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Tan Dun <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The DXE & MM standalone variant of AcpiTimerLib defines a global
named mPerformanceCounterFrequency. A global with an identical
name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
Since XhciDxe has a dependency on TimerLib, this can cause link
errors due to the same symbol being defined twice if the platform
DSC chooses to use AcpiTimerLib as the TimerLib implementation for
any given platform.
To resolve this, I noted that some of the globals in Xhci.c are not
used outside of the Xhci.c compilation unit:
- mPerformanceCounterStartValue
- mPerformanceCounterEndValue
- mPerformanceCounterFrequency
- mPerformanceCounterValuesCached
I have changed the definition for all of these to static and added
an Xhci prefix. Since they are not used outside of the Xhci.c
compilation unit, there is no reason to have them exported as
globals.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
The DXE & MM standalone variant of AcpiTimerLib defines a global
named mPerformanceCounterFrequency. A global with an identical
name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
Since XhciDxe has a dependency on TimerLib, this can cause link
errors due to the same symbol being defined twice if the platform
DSC chooses to use AcpiTimerLib as the TimerLib implementation for
any given platform.
To resolve this, I have changed made the definition of
mPerformanceCounterFrequency to static and renamed it to
mAcpiTimerLibTscFrequency. Since this variable is not used outside
of the DxeStandaloneMmAcpiTimerLib.c compilation unit, there is no
reason to have it exported as a global.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
__builtin_return_address returns a pointer, not a string. Fix
the STACK FAULT message in BaseStackCheckLib appropriately.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Currently, there are code to set memory attribute in CpuMpPei module.
However, the code doesn't handle the case of 5 level paging.
Use the CpuPageTableLib to set memory attribute for two purpose:
1. Add 5 level paging support
2. Clean up code
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The local variable OneOfPagingEntry is used before initialized, this
may cause reserved bit in page table entry is set especially in PAE
paging mode. The bug is random because it depends on the value in
stack.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4609
The current CalculateCrc16Ansi implementation does the following:
1) Invert the passed checksum
2) Calculate the new checksum by going through data and using the
lookup table
3) Invert it back again
This emulated my design for CalculateCrc32c, where 0 is
passed as the initial checksum, and it inverts in the end.
However, CRC16 does not invert the checksum on input and output.
So this is incorrect.
Fix the problem by not inverting input checksums nor output checksums.
Callers should now pass CRC16ANSI_INIT as the initial value instead of
"0". This is a breaking change.
This problem was found out-of-list when older ext4 filesystems
(that use crc16 checksums) failed to mount with "corruption".
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4610
Google Test hides test registration in global constructors on global
objects. Global constructors are traditionally implemented by placing
references to the global constructor's symbol in special sections
(traditionally named .ctors or .init_array). These sections are not
explicitly referenced by the linker, and libc only looks at special
start and end symbols (and calls them).
This works fine if you're linking a program manually using
gcc a.o b.o c.o -o test_suite
but fails miserably when using static libraries (such as what EDK2
does), because traditional static archive symbol resolution rules don't
allow for object files to be pulled in to the link if there isn't an
undefined symbol reference to that .o elsewhere.
Fix it by passing --whole-archive (GCC) and /WHOLEARCHIVE (MSVC). These
options force the linker to pull in the entire static library, thus
including previously-unreferenced constructors and making sure
multi-file gtest EDK2 components work.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Cc: Michael D Kinney <michael.d.kinney@intel.com>
CoreLocateDevicePath is used in CoreInstallMultipleProtocolInterfaces to
check if a Device Path Protocol instance with the same device path is
alreay installed.
CoreLocateDevicePath is a generic API, and would introduce some
unnecessary overhead for such usage.
The optimization is:
1. Implement IsDevicePathInstalled to loop all the Device Path
Protocols installed and check if any of them matchs the given device
path.
2. Replace CoreLocateDevicePath with IsDevicePathInstalled in
CoreInstallMultipleProtocolInterfaces.
This optimization could save several seconds in PCI enumeration on a
system with many PCI devices.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Ancient GCC 4.8.5 warned about variable may be unitialied.
And it doesn't look like false alarm.
The warning is:
edk2/RedfishPkg/Library/HiiUtilityLib/HiiUtilityInternal.c: In function 'GetQuestionDefault':
edk2/RedfishPkg/Library/HiiUtilityLib/HiiUtilityInternal.c:5519:6: error: 'ConfigAccess' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (ConfigAccess != NULL) {
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
AndroidBootImgLib allows for platforms to append to kernel command
line but does not allow for the overall kernel command line to go
beyond the limit set by the image header. Address this limitation
by adding a pcd where platform can tell how many extra characters
they expect on their platform in addition to what the image header
specifies.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Curently, AndroidBootImgLib expects input kernel command line
to never exceed 256 unicode characters where the image header
allows for 512 ascii characters. If image header allows 512
ascii characters, similar number of unicode characters should be
allowed at the minimum.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
