OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM
According to edk2 commit
"MdeModulePkg/PciBus: do not improperly degrade resource"
and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
Platform Init 1.4a specification, a platform can provide such a protocol
in order to influence the PCI resource allocation performed by the PCI Bus
driver.
In particular it is possible instruct the PCI Bus driver, with a
"wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
address space, regardless of whether the device features an option ROM.
(By default, the PCI Bus driver considers an option ROM reason enough for
allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
binary from a combined option ROM could be dispatched, and fail to access
MMIO BARs in 64-bit address space.)
In platform code we can ascertain whether a CSM is present or not. If not,
then legacy BIOS binaries in option ROMs can't be dispatched, hence the
BAR degradation is detrimental, and we should prevent it. This is expected
to conserve the 32-bit address space for 32-bit MMIO BARs.
The driver added in this patch could be simplified based on the following
facts:
- In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
the driver will exit immediately. Therefore the driver could be omitted
from the Ia32 build.
- In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
was defined (because in that case the degradation would be justified).
On the other hand, if CSM_ENABLE was undefined, then the driver could be
included, and it could provide the hint unconditionally (without looking
for the Legacy BIOS protocol).
These short-cuts are not taken because they would increase the differences
between the OVMF DSC/FDF files. If we can manage without extreme
complexity, we should use dynamic logic (vs. build time configuration),
plus keep conditional compilation to a minimum.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-05-18 20:13:41 +02:00
|
|
|
## @file
|
|
|
|
|
# A simple DXE_DRIVER that causes the PCI Bus UEFI_DRIVER to allocate 64-bit
|
|
|
|
|
# MMIO BARs above 4 GB, regardless of option ROM availability (as long as a CSM
|
|
|
|
|
# is not present), conserving 32-bit MMIO aperture for 32-bit BARs.
|
|
|
|
|
#
|
|
|
|
|
# Copyright (C) 2016, Red Hat, Inc.
|
|
|
|
|
#
|
2019-04-04 01:06:33 +02:00
|
|
|
# SPDX-License-Identifier: BSD-2-Clause-Patent
|
OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM
According to edk2 commit
"MdeModulePkg/PciBus: do not improperly degrade resource"
and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
Platform Init 1.4a specification, a platform can provide such a protocol
in order to influence the PCI resource allocation performed by the PCI Bus
driver.
In particular it is possible instruct the PCI Bus driver, with a
"wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
address space, regardless of whether the device features an option ROM.
(By default, the PCI Bus driver considers an option ROM reason enough for
allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
binary from a combined option ROM could be dispatched, and fail to access
MMIO BARs in 64-bit address space.)
In platform code we can ascertain whether a CSM is present or not. If not,
then legacy BIOS binaries in option ROMs can't be dispatched, hence the
BAR degradation is detrimental, and we should prevent it. This is expected
to conserve the 32-bit address space for 32-bit MMIO BARs.
The driver added in this patch could be simplified based on the following
facts:
- In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
the driver will exit immediately. Therefore the driver could be omitted
from the Ia32 build.
- In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
was defined (because in that case the degradation would be justified).
On the other hand, if CSM_ENABLE was undefined, then the driver could be
included, and it could provide the hint unconditionally (without looking
for the Legacy BIOS protocol).
These short-cuts are not taken because they would increase the differences
between the OVMF DSC/FDF files. If we can manage without extreme
complexity, we should use dynamic logic (vs. build time configuration),
plus keep conditional compilation to a minimum.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-05-18 20:13:41 +02:00
|
|
|
##
|
|
|
|
|
|
|
|
|
|
[Defines]
|
|
|
|
|
INF_VERSION = 0x00010005
|
|
|
|
|
BASE_NAME = IncompatiblePciDeviceSupportDxe
|
|
|
|
|
FILE_GUID = F6697AC4-A776-4EE1-B643-1FEFF2B615BB
|
|
|
|
|
MODULE_TYPE = DXE_DRIVER
|
|
|
|
|
VERSION_STRING = 1.0
|
|
|
|
|
ENTRY_POINT = DriverInitialize
|
|
|
|
|
|
|
|
|
|
[Sources]
|
|
|
|
|
IncompatiblePciDeviceSupport.c
|
|
|
|
|
|
|
|
|
|
[Packages]
|
|
|
|
|
IntelFrameworkPkg/IntelFrameworkPkg.dec
|
|
|
|
|
MdeModulePkg/MdeModulePkg.dec
|
|
|
|
|
MdePkg/MdePkg.dec
|
|
|
|
|
OvmfPkg/OvmfPkg.dec
|
|
|
|
|
|
|
|
|
|
[LibraryClasses]
|
|
|
|
|
DebugLib
|
|
|
|
|
MemoryAllocationLib
|
|
|
|
|
PcdLib
|
|
|
|
|
UefiBootServicesTableLib
|
|
|
|
|
UefiDriverEntryPoint
|
|
|
|
|
|
|
|
|
|
[Protocols]
|
|
|
|
|
gEfiIncompatiblePciDeviceSupportProtocolGuid ## SOMETIMES_PRODUCES
|
|
|
|
|
gEfiLegacyBiosProtocolGuid ## NOTIFY
|
|
|
|
|
|
|
|
|
|
[Pcd]
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration ## CONSUMES
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size ## CONSUMES
|
|
|
|
|
|
|
|
|
|
[Depex]
|
|
|
|
|
TRUE
|
