The ProcessOptionRomLight() assumes that OpRom has already been
processed in the previous full enumeration and updates
AllOpRomProcessed flag to TRUE by default. However, this may not
be applicable with other pre-stage boot firmwares.
This will update AllOpRomProcessed flag properly by checking
PciRomGetImageMapping().
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3149
Address MEM64 BAR in type unknown if sizing fail in high 32bit.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Zarcd Zhong <zarcd.zhong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=313
Add PcdPcieResizableBarSupport to enable/disable PCIe Resizable
BAR Capability fearture.
Program the Resizable BAR Register if the device suports PCIe Resizable
BAR Capability and PcdPcieResizableBarSupport is TRUE.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Heng Luo <heng.luo@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2515
Change the MdeModulePkg to match the ECC check rule
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
Whenever a PCI device is discovered, PCI bus calls the
EDKII_DEVICE_SECURITY_PROTOCOL to authenticate it.
If the function returns success, the PCI bus allocates
the resource and installs the PCI_IO for the device.
If the function returns fail, the PCI bus skips the device.
It is similar to EFI_SECURITY_ARCH_PROTOCOL, which
is used to verify an EFI image.
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>
Cc: Yun Lou <yun.lou@intel.com>
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Per PCIE spec, Memory Write and Invalidate is hardwired to 0b so
PciBus driver shouldn't write 1b to it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
This reverts commit 5db417ed25.
"MdeModulePkg/PciBusDxe: Enable Bus Master on P2P bridges on demand"
We met some compatibility issues when doing Windows S4 resume.
Reverting the BME disabling patches to fix the S4 resume issue.
Signed-off-by: Ruiyu Ni <Ruiyu.ni@intel.com>
Signed-off-by: Michael Turner <michael.turner@microsoft.com>
Cc: Michael D Kinney <Michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The patch dynamically enables Bus Master on P2P bridges only
when requested by a device driver through PciIo.Attribute() to enable
the Bus Master.
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Compiler calculates the PciBar[BarIndex] using
sizeof (PciBar[0]) * BarIndex, when BarIndex is type of UINT64,
the above calculation generates assembly code using _allmul.
Change BarIndex to UINTN to avoid the build failure.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
PI spec IncompatiblePciSupport part defines (UINT64)-1 as all BARs
and 0 to use existing alignment. PciBus driver didn't accept these
values. It treated 0xFF as all BARs and 0xFFFFFFFFFFFFFFFFULL to use
existing alignment.
The patch changes the code to still accept old values while also
accept values defined in PI spec. So that the driver can provide
backward compatibility and follow spec.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
PciBus driver originally always degrade (64->32) the MMIO resource
for PCI BAR when the PCI device contains option ROM.
But the degrade causes the PCI device can only use resource below 4GB
which makes the resource allocation fails when the PCI device wants
very big MMIO.
The patch follows the PI spec (ECR 1529) to honor the granularity
setting for PCI BAR from IncompatiblePciDeviceSupport so that even
for PCI device which contains option ROM, the degrade doesn't happen
if IncompatiblePciDeviceSupport returns 64 as granularity.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Remove "Efi" from gEfiIncompatiblePciDeviceSupport to shorten
the global variable name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
When PcdPciDisableBusEnumeration is enabled, the PciBus driver
might get into a dead loop if the secondary bus register on PCI
bridge is not programmed or programmed improperly. Adding this
check to avoid any potential dead loop caused by this.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Lee Leahy <Leroy.p.leahy@intel.com>
The resource dumping logic contains a bug which cannot dump the
resource for hot plug controller correctly. The patch fixes this
bug.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18718 6f19259b-4bc3-4df7-8a09-765794883524
Leif suggested to split the big patch to smaller ones.
This reverts commit 73b7f115c653c807b9d0be97bf516871d8aff7ba.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18717 6f19259b-4bc3-4df7-8a09-765794883524
Add a check for ResourcePaddingDescriptors being a valid pointer in
DumpPpbPaddingResource() to prevent looping on memory not owned by
PciBusDxe. The ResourcePaddingDescriptors is initialized to NULL
when the PCI_IO_DEVICE structure is allocated and remains NULL if
no PCI hot plug controllers are present. This issue is only
observed when DEBUG_CODE() macros are enabled and was introduced
by the following patch:
[edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug
SVN revsion 18658
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Kinney Michael <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18696 6f19259b-4bc3-4df7-8a09-765794883524
For a hot plug bridge with device attached, PciBusDxe driver reserves
the resources which equal to the total amount of padding resource
returned from HotPlug->GetResourcePadding() and the actual occupied
resource by the attached device. The behavior is incorrect.
Correct behavior is to reserve the bigger one between the padding
resource and the actual occupied resource.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18658 6f19259b-4bc3-4df7-8a09-765794883524
When looping through all PCI functions, code should not look for functions
1-7 if function 0 is not present or if function 0 indicates the device is
not multifunction. Prior to this fix the code would use stale data in a
buffer to determine if a device is multifunction even if function 0 is not
present. This fixes a code bug and provides very small performance
improvements.
PCI 2.3 Specification states: They [multifunction devices] are also
required to always implement function 0 in the device. Implementing other
functions is optional and may be assigned in any order.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Joseph Shifflett <joseph.shifflett@hpe.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18574 6f19259b-4bc3-4df7-8a09-765794883524
According to the PCI spec, when software writes all-one to BAR for size probing,
the value read back should be 0b1...10...0 after masking the BAR type bits.
But in real world, it's possible that certain device returns 0b0...01...10...0
for MEM64 BAR size probing: some bits in the high 32bit may be 0.
PciBus driver has the code to handle such case. However, it doesn't handle the
case that the high 32bit is totally 0. The patch is to handle the special case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18114 6f19259b-4bc3-4df7-8a09-765794883524
creation) of PciIoDevice->DevicePath. The bug can be triggered when
PciBusDxe is built into OVMF, with qemu/KVM device assignment of
a PCI-express device on the default 440FX machine type. OVMF
correctly discovers that the device is PCIe and begins probing
extended configuration space for the device. The root bridge
has no way to access extended config space and correctly errors,
sending us into the error reporting chain seen below. It's
possible that this error path could also be reproduced on physical
hardware when a PCI-to-PCIe bridge is present.
GatherDeviceInfo() | GatherPpbInfo() | GatherP2CInfo() [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
CreatePciIoDevice() [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
AllocateZeroPool()
LocateCapabilityRegBlock() [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
PciIoDevice->IsPciExp = TRUE
LocatePciExpressCapabilityRegBlock() [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
PciIoConfigRead() via funcptr [MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c]
RootBridgeIoPciRead() via funcptr [PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c]
FAILS
REPORT_STATUS_CODE_WITH_DEVICE_PATH() [MdePkg/Include/Library/ReportStatusCodeLib.h]
ReportStatusCodeWithDevicePath() [MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c]
ASSERT (DevicePath != NULL) <--+
CreatePciDevicePath() | [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
sets PciIoDevice->DevicePath ----------+
In English:
- CreatePciIoDevice() allocates a zeroed out PCI_IO_DEVICE structure.
- PciIoConfigRead() tries to access the (extended) config space, and
fails.
- PciIoConfigRead() wants to report a status code (read error) for the
device path.
- Unfortuantely, PciIoDevice->DevicePath is still NULL at that point.
- The ASSERT() in ReportStatusCodeWithDevicePath() fires.
Fix it by moving CreatePciDevicePath() into CreatePciIoDevice(),
allowing PciIoDevice->DevicePath to be initialized before we
begin probing the device capabilities:
GatherDeviceInfo() | GatherPpbInfo() | GatherP2CInfo() [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
CreatePciIoDevice() [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
AllocateZeroPool()
CreatePciDevicePath() [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
sets PciIoDevice->DevicePath -----------+
LocateCapabilityRegBlock() | [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
PciIoDevice->IsPciExp = TRUE |
LocatePciExpressCapabilityRegBlock() | [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
PciIoConfigRead() via funcptr | [MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c]
RootBridgeIoPciRead() via funcptr | [PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c]
FAILS |
REPORT_STATUS_CODE_WITH_DEVICE_PATH() | [MdePkg/Include/Library/ReportStatusCodeLib.h]
ReportStatusCodeWithDevicePath() | [MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c]
ASSERT (DevicePath != NULL) <-----+
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15567 6f19259b-4bc3-4df7-8a09-765794883524
1. Fix the incorrect definition of EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 (does not conform to the UEFI spec) in PciIo.h.
2. Add missing definitions of ISA and VGA IO attributes in PCI Root Bridge IO protocol.
3. Improve the algorithm in the PCI bus driver to get PCI platform policy from PCI Platform Protocol and PCI Override Protocol.
4. Update the PCI bus driver to use the PCI platform policy to determine the supported attributes that are returned by the EFI_PCI_IO_PROTOCOL.Attributes() function. This is required by the PI spec.
5. Add a backward compatibility workaround for PCI VGA drivers in Option ROM, which typically sets VGA_IO without checking supported attributes.
6. Update the PCI host bridge driver in PcAtChipsetPkg to report VGA_IO_16 and ISA_IO_16 instead of VGA_IO/ISA_IO attributes. Modern chipsets don’t have hardware capability to control 10-bit or 16-bit decoding for ISA/VGA aliases.
7. Update LPC/VGA device drivers to check supported attributes of VGA_IO/VGA_IO_16 or ISA_IO/ISA_IO_16.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11204 6f19259b-4bc3-4df7-8a09-765794883524
1. Expand the type of Offset in the _PCI_BAR structure from UINT8 to UINT16, because a VF BAR’s offset may be >= 0x100;
2. Enable ARI Capable Hierarchy for SR-IOV devices at earlier time because FirstVFOffset and VFStride of a SR-IOV device may change after its ARI Capable Hierarchy is set;
3. Change type of PcdSrIovSupport, PcdAriSupport, PcdMrIovSupport from FeatureFlag to [FixAtBuild, PcdDynamics], which allows SR-IOV/MR-IOV/ARI feature can be turn on/off dynamically, typically via a setup option.
4. Change PCI bus scan algorithm in PciScanBus() to prevent the case where some ARI extended functions may be skipped in the scan loop.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10644 6f19259b-4bc3-4df7-8a09-765794883524
a. Update PciBusDxe module, and move it from IntelFrameworkModulePkg to MdeModulePkg
b. Move IncompatiblePciDeviceSupportDxe module from IntelFrameworkModulePkg to MdeModulePkg
c. Update the related consumes in inf/dsc/fdf
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9347 6f19259b-4bc3-4df7-8a09-765794883524
Aiden Park
Zarcd Zhong
Luo, Heng
GuoMinJ
Jiewen Yao
Michael D Kinney
Ray Ni
Liming Gao
Ruiyu Ni
Gary Lin
Ma, Maurice
Joseph Shifflett
Feng Tian
Alex Williamson
niruiyu
rsun3
hhtian
mdkinney
davidhuang