On Wed, 22 Jun 2022 at 17:35, Ard Biesheuvel <a...@kernel.org> wrote: > > On Tue, 21 Jun 2022 at 23:28, Nicolas Ojeda Leon <ncol...@amazon.com> wrote: > > > > Increased control is provided in Ovmf platforms to define and configure > > the specifications of multiple PCI host bridges in the hypervisor. The > > host propagates this information to the guest, initially through fw-cfg > > interface. > > > > In some AWS EC2 platforms, we expose a PCI topology including several > > root bridges portraying information about physical distribution that > > enables the guest to optimize accesses. Current PCI driver for Ovmf > > enables the explicit definition of multiple root bridges and contains > > the logic to fix their resources based on platform-specific PCD > > entries. However, we need a way to control, from the hypervisor, how > > many and which resources each PCI root bridge can use. For this > > reason, this patch series introduces a mechanism to provide PCI host > > bridges information like bus number range, attributes, allocation > > attributes, PIO aperture as well as 32 and 64- bit prefetchable and > > non-prefetchable MMIO ranges through a fw-cfg item created by the > > hypervisor and consumed by the guest firmware. In order to offer a > > generic and extensible way to disclose non-discoverable hardware > > information from the host to the guest, a new library called > > HardwareInfoLib is created in the OvmfPkg. In essence, this library > > offers the functionality to parse a generic BLOB into a list as well > > as the methods to iterate over such list, including filtering options. > > The library is conceived in a generic way so that further hardware > > elements can also be described using it. For such purpose the length > > of the BLOB is not restricted but instead regarded as a sequence of > > header-info elements that allow the parsing during runtime. > > Furthermore, specific functionality is provided wrapping > > QemuFwCfgReadBytes to extract hardware descriptions, in the > > aforementioned format, in a static way so that early in the Pei > > stage the library can be used to identify address space requirements. > > The core of the library offers enough flexibility to process as many > > elements, even from different hardware types (heterogenous), as needed > > in a single run. This library is extended for the particular use case > > already exposed, PCI host bridges, and this same code offers an > > example of how to tailor it for further hardware components. > > > > After acknowledgement from Gerd Hoffmann and fixing all warnings and > > errors found by the CI pipeline (via draft pull request), here I send > > a new revision of the patches for merging. > > > > --- > > Notes: > > v6: > > Prepearation for upstream merge: > > - No functional change at all. > > - Small changes to fix all builds excercised by CI > > (https://github.com/tianocore/edk2/pull/2938) > > - Added libraries to furhter platforms as per dependencies requirements > > - Explicit casting of some values as required by build and > > verification of values when demoting values. > > - Arranged added files copyright to the format required. > > - Changed HOST_BRIDGE_INFO bitfield member to UINT32 to follow > > EDK2 guidelines motivated on build in 32-bit windows systems. > > - Added verification of Bus Number range when values provided by > > host to make sure Root Bridge is initialized with valid values > > > > v5: > > - Removed last 3 patches dealing with pre-populated resources to > > encapsulate related changes in more manageable chunks and while > > pre-populated changes are finalized. > > - Added Acked-by to all commits > > - Re-based on top of latest master and refactored changes in > > MemDetect.c to adapt to recently created > > PlatformInitLib/MemDetect.c > > > > v4: > > - Minor modification to use MAX_UINT64 as global invalid base address > > when reading PCI host bridge information provided by the host > > (Patch 1) > > - Refactor PciHostBridgeUtilityGetRootBridges into a thin wrapper that > > calls 2 new function: one (BusScan) that performs the legacy bus > > scan population process and a new one (HostProvided) that populates > > Root Bridges with host provided values. (Patch 5) > > - Move code that sets value of PcdPciPreservePopulatedMappings token > > based on host-provided fw-cfg file into the function that populates > > root bridges with host provided data (Patch 6) > > - Restructured base address retrieval to leave PCI Resource Allocation > > protocol untouched and instead augment the existing services to > > enable base address retrieval before allocation. (Patch 7) > > - Use new method to retrieve Root Bridge base addresses before > > allocation and use that to handle pre-populated BARs (Patch 8) > > > > > > Nicolas Ojeda Leon (5): > > OvmfPkg/Library: Create base HardwareInfoLib for PCI Host Bridges > > Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfg > > Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous > > data > > Ovmf/PlatformPei: Use host-provided GPA end if available > > OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with > > spec > > > > Merged as #3000, > > Thanks all, >
This series appears to have triggered a failure in our CI. Could someone propose a fix please? https://ci.linaro.org/job/leg-virt-tianocore-edk2-upstream/4563/ -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90716): https://edk2.groups.io/g/devel/message/90716 Mute This Topic: https://groups.io/mt/91909735/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
