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
Platforms such as Xen already enumerates PCI bridges and devices. Use
this PCD to control EDK2 behavior.
PcdPciDisableBusEnumeration is placed under [PcdsFixedAtBuild,
PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx], so that it is
possible to alter it during runtime.
The default setting of this PCD is false (allow full PCI enumeration) to
preserve the same behavior before this change.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14940 6f19259b-4bc3-4df7-8a09-765794883524
the PCI Bus driver through the function call NotifyPhase().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14483 6f19259b-4bc3-4df7-8a09-765794883524
Signed-off-by: Sun Rui <rui.sun@intel.com>
Reviewed-by: Fan Jeff <jeff.fan@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13189 6f19259b-4bc3-4df7-8a09-765794883524
* Check if the machine type of the image is supported by the current UEFI system.
* Ignore the image if it is an EFI application as required by the UEFI spec.
Signed-off-by: rsun3
Reviewed-by: li-elvin
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12465 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
This check-in fix the issue by adding a flag to indicate if a HPC is found during PCI enumeration or not. This check-in also adds a debug message if any found HPC failed with initialization.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11081 6f19259b-4bc3-4df7-8a09-765794883524
This solution defines a PCD Feature Flag to enabled support for unaligned requests through the PCI I/O Protocol. This flag is disabled by default. Platforms that do want to support such EFI/UEFI drivers that make unaligned PCI I/O requests should enable this feature.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11016 6f19259b-4bc3-4df7-8a09-765794883524
But current PCI bus driver has a bug that if a P2P bridge has no child devices detected during enumeration, the bits won’t be set. This may impact PCI hot plug capable bridges because the OS may re-assign resources for them causing the reserved resource by the firmware will be overwritten.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11013 6f19259b-4bc3-4df7-8a09-765794883524
These comparisons were not comparing an enum variable
with a member of the same enum type.
GCC 4.5 generated a warning for these comparison
operations.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10932 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 linked list is created for the list of PCI Root Bridges in the platform. This list is then traversed to enumerate each PCI Root Bridge. After enumeration, the RootBridgeDev is destroyed, but it was not removed from the linked list before it was destroyed. This left the linked list of PCI Root Bridges in a bad state, specially if memory is cleared on frees, or the freed buffer was reallocated.
The fix is to remove the node from the linked list before the RootBridgeDev is destroyed.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10463 6f19259b-4bc3-4df7-8a09-765794883524