The <FrameworkDxe.h> header is not used by any source file at this point,
remove it.
<FrameworkDxe.h> is a thin wrapper for including all header files under
the "OvmfPkg/Csm/Include/Framework" directory. Remove that directory at
the same time (nothing else references contents in that directory
directly).
Consequently, the "OvmfPkg/Csm/Include" directory becomes empty, and git
automatically deletes it; remove that include path from
"OvmfPkg/OvmfPkg.dec".
This shrinks the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
- gEfiLegacy8259ProtocolGuid
- headers:
- Protocol/Legacy8259.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-28-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>
At this point, gEfiLegacyInterruptProtocolGuid is unused; remove it.
This shrinks the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
- gEfiLegacy8259ProtocolGuid
- headers:
- FrameworkDxe.h
- Protocol/Legacy8259.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-27-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>
CsmSupportLib 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):
- SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
- gEfiFirmwareVolumeProtocolGuid (by cutting the
<Protocol/FirmwareVolume.h> link)
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Protocol/FirmwareVolume.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
- gEfiFirmwareVolumeProtocolGuid
- gEfiLegacy8259ProtocolGuid
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Protocol/FirmwareVolume.h
- Protocol/Legacy8259.h
- Protocol/LegacyBios.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
[*] 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-23-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>
CsmSupportLib is effectively a hack. It produces the following protocols:
- Legacy Bios Platform,
- Legacy Interrupt,
- Legacy Region2.
(Note that the "OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf" file contains
an error where it claims that "Legacy Bios Platform" is "consumed" -- it
is not; the lib instance produces that protocol).
At the same time, the library instance consumes
gEfiLegacyBiosProtocolGuid.
This *seemingly* creates a circular dependency with LegacyBiosDxe, because
that driver has the exact opposite protocol usage patterns. The solution
is that LegacyBiosDxe has a DEPEX on the protocols produced by
CsmSupportLib, while CsmSupportLib consumes the Legacy Bios Protocol from
LegacyBiosDxe only in the member functions of the protocols it produces.
Therefore, once BdsDxe is dispatched, and the CsmSupportLib constructor
exposes those three protocols, LegacyBiosDxe can also be started by the
DXE dispatcher, and then the protocols from CsmSupportLib become
functional.
But the main reason why CsmSupportLib is a hack is that it should be a
normal platform DXE driver (called e.g. "CsmSupportDxe"), and not a NULL
class library that's randomly hooked into BdsDxe.
Given that we have removed LegacyBiosDxe earlier (so there is no DEPEX we
need to satisfy now, conceptually), unhook CsmSupportLib from BdsDxe.
--*--
Note that in the BhyveX64 platform, the pathname
"OvmfPkg/Bhyve/Csm/CsmSupportLib/CsmSupportLib.inf" is bogus, and has
always been, since commit 656419f922 ("Add BhyvePkg, to support the
bhyve hypervisor", 2020-07-31).
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-22-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>
NullMemoryTestDxe was included in the OVMF platforms in historical commit
999a815e9f ("OvmfPkg: Add NullMemoryTestDxe driver", 2011-01-21). It
produces gEfiGenericMemTestProtocolGuid. With LegacyBiosDxe gone, the only
consumer of this protocol in all of edk2 is
"EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c". Thus, exclude
NullMemoryTestDxe from all OVMF platforms.
(Notably, ArmVirtPkg platforms don't include NullMemoryTestDxe either.)
Cc: Anatol Belski <anbelski@linux.microsoft.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Corvin Köhne <corvink@freebsd.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jianyong Wu <jianyong.wu@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-17-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>
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>
This reverts commit c7341877f6.
That commit was a later (2019-06-26), heavier weight exclusion of 64-bit
BARs when a CSM was included, and is similarly superfluous now, so revert
it.
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-15-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>
LegacyBiosDxe is the core CSM driver. It procudes
gEfiLegacyBiosProtocolGuid, on top of several smaller, more foundational
legacy BIOS protocols, whose drivers we've not excluded yet. In the course
of tearing down CSM support in (reverse) dependency order, exclude
LegacyBiosDxe at this point.
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-13-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>
At this point, gEfiLegacyDevOrderVariableGuid is unused; remove it.
This shrinks the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- headers:
- 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-8-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>
PcdCsmEnable was introduced in commits 50f911d25d ("OvmfPkg: introduce
PcdCsmEnable feature flag", 2020-02-05) and 75839f977d
("OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)",
2020-02-05). Remove it, and substitute constant FALSE wherever it has been
evaluated thus far.
Regression test: after building OVMF IA32X64 with -D SMM_REQUIRE, and
booting it on Q35, the log still contains
> Q35SmramAtDefaultSmbaseInitialization: SMRAM at default SMBASE found
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-3-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>
We're going to gradually tear down and remove the Compatibility Support
Module (CSM) in OvmfPkg (due to it having no maintainer). Start by making
all platforms that have thus far accepted "-D CSM_ENABLE" reject that
macro, so that mid-series, the partially removed infrastructure cannot be
built or booted.
Insert an !error directive in each DSC file's first "!ifdef $(CSM_ENABLE)"
conditional.
At the end of the series, the !error directive introduced in this patch
will be removed.
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-2-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>
Bhyve uses an io port range of [ 0x2000, 0x10000 ] [1]. At the moment,
EDKII is using a subset of this range [ 0xC000, 0x10000 ] [2]. Even
though the EDKII range doesn't exceed the bhyve range, it's causing
issues on some guests like OpenBSD [3]. We don't know why it's causing
issues yet. However, using the same IO port range in EDKII fixes the
issue and is a good idea anyway.
[1] 82ea0132c8/usr.sbin/bhyve/pci_emul.c (L133-L134)
[2] fb044b7fe8/OvmfPkg/Bhyve/PlatformPei/Platform.c (L156-L157)
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274389
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jiewen Yao <jiewen.yao@intel.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>
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>
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>
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>
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>
Refine test case:
1. Check PAE paging reserved bits is zero.
2. Set stack as random value.
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=4591
1. Refer NVME spec 2.0c chapter 5.24, add Sanitize Command
related definition.
2. Refer NVME spec 2.0c chapter 5.16, add Get Log Page
Command related definition for Sanitize status support.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Xiao X Chen <xiao.x.chen@intel.com>
Cc: Arthur Chen <arthur.g.chen@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Tina Chen <tina.chen@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Wrong memory allocation issue may result in memory
corruption.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
The size of structure must be minus with byte that is
occupied by the initial array.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
MAC address reference is incorrect when it is
copied to Host Interface DeviceDescriptor.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Wait until Redfish Host Interface is installed on
the system then acquire Redfish service.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Introduce gEdkIIRedfishHostInterfaceReadyProtocolGuid
and produce it when Redfish Host Interface is installed
on system.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Update BMC USB NIC searching algorithm for IPv4 only.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Co-authored-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Add GoogleTestBaseLib, which contains gtest unit tests for BaseLib.
For now, only add checksum tests for CRC32C and CRC16; these tests check
for correctness on various inputs using precomputed hashes.
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>
Laszlo Ersek
Corvin Köhne
Sheng Wei
Nate DeSimone
Jake Garver
Zhiguang Liu
Tina Chen
Abner Chang
Pedro Falcato