In V4: Update the copyright to 2023.
In V3: Add AMD copyright.
In V2: Remove the signed-off-by: Abner Chang
Display PCIe Vendor ID and Device ID in DEBUG message.
Signed-off-by: Jiangang He <jiangang.he@amd.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Garrett Kirkendall <garrett.kirkendall@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
If a device which support both features SR-IOV/ARI has multi
functions, which maybe support 8-255. After enable ARI forwarding in
the root port and ARI Capable Hierarchy in the SR-IOV PF0.
The device will support and expose multi functions(0-255) with ARI ID routing.
In next device loop in below for() code, actually it still be in the
same SR-IOV device, and just some PF which is over 8 or higher
one(n*8), PciAllocateBusNumber() will allocate bus
number(ReservedBusNum - TempReservedBusNum)) for this PF. if reset
TempReservedBusNum as 0 in this case,it will allocate wrong bus number
for this PF because TempReservedBusNum should be total previous PF's
reserved bus numbers.
code:
for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
TempReservedBusNum = 0;
for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {
//
// Check to see whether a pci device is present
//
Status = PciDevicePresent (
PciRootBridgeIo,
&Pci,
StartBusNumber,
Device,
Func
);
...
Status = PciAllocateBusNumber (PciDevice, *SubBusNumber,
(UINT8)(PciDevice->ReservedBusNum - TempReservedBusNum), SubBusNumber);
The solution is add a new flag IsAriEnabled to help handle this case.
if ARI is enabled, then TempReservedBusNum will not be reset again
during all functions(1-255) scan with checking flag IsAriEnabled.
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Below code will calculate the reserved bus number for the each PF.
Based on the VF routing ID algorithm, PFRid and LastVF in below code
already sure that "All VFs and PFs must have distinct Routing IDs".
PF will be assigned Routing ID based on secBusNumber, ReservedBusNum
will add into SubBusNumber directly. So the SR-IOV device will be
assigned bus range as SecBusNumber ~ (SubBusNumber=(SecBusNumber +
ReservedBusNum)).
Thus "+1" in below code will cause extra 1 bus, and introduce a bus hole.
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus + 1);
In SR-IOV spec, there is a note in section 2.1.2:
Note: Bus Numbers are a constrained resource. Devices are strongly
encouraged to avoid leaving ?holes? in their Bus Number usage to avoid
wasting Bus Numbers
So the issue can be fixed with below code change.
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus);
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Per the section 3.3.5 SR-IOV spec v1.1, InitialVFs (0ch).
InitialVFs indicates to SR-PCIM the number of VFs that are initially associated with the PF.
The minimum value of InitialVFs is 0.
Below code is used to calculate SR-IOV reserved bus number,
if InitialVFs =0, it maybe calculate the wrong bus number in this case.
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride
we can fix it with below code:
if (PciIoDevice->InitialVFs == 0) {
PciIoDevice->ReservedBusNum = 0;
} else {
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
//
// Calculate ReservedBusNum for this PF
//
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1);
//
// Calculate ReservedBusNum for this PF
//
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1);
}
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Function of UpdatePciInfo() in PciEnumeratorSupport.c is used to update
the bar information for those incompatible PCI device. It is the right
place to check if the OptionRom need to be ignored.
According to "Table 20. ACPI 2.0 & 3.0 QWORD Address Space Descriptor
Usage" in PI Spec 1.7, Type-specific flags can be set to 0 when Address
Translation Offset == 6 to skip device option ROM (do not probe option
rom BAR).
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Before trying to access parent root port to check ARI capabilities,
enumerator should see if Endpoint device is not Root Complex integrated
to avoid undefined parent register accesses.
Signed-off-by: Damian Bassa <damian.bassa@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the MdeModulePkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
https://bugzilla.tianocore.org/show_bug.cgi?id=3635
Currently, in order to test the supported attributes,
the PciTestSupportedAttribute() will set the command register
to 0x27 (EFI_PCI_COMMAND_IO_SPACE, EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER, EFI_PCI_COMMAND_VGA_PALETTE_SNOOP) firstly,
and then read back to check whether these attributes are
set successfully in the device.
This will cause the other enabled bits
(other than EFI_PCI_COMMAND_IO_SPACE,EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER,EFI_PCI_COMMAND_VGA_PALETTE_SNOOP)
be cleared for a short of time
This patch fixes this issue by keeping the origina
enabled bits when setting 0x27.
Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
Reviewed-by: Ray <ray.ni@intel.com>
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
Abner Chang
Foster Nong
Min Xu
Ray Ni
Michael Kubacki
Michael D Kinney
xueshengfeng
Aiden Park
Zarcd Zhong
Luo, Heng
GuoMinJ
Jiewen Yao
Liming Gao
Ruiyu Ni
Gary Lin
Ma, Maurice
Joseph Shifflett
Feng Tian
Alex Williamson
niruiyu
rsun3
hhtian
mdkinney