From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web08.5997.1655982057226625985 for ; Thu, 23 Jun 2022 04:00:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TGhzW+BG; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 81EBA61ED8 for ; Thu, 23 Jun 2022 11:00:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64E2AC341CC for ; Thu, 23 Jun 2022 11:00:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655982055; bh=rOjWJqJzADfsJo2LLEmR6edyWMkN0z61NFYvdvX5OJs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TGhzW+BG6J7y6dhF02MZCDcAnKqLl8/pYUJMEfTOWLWExFmnyG8LZDBG9V0FVUG6z vIE8yf7d//A/KlmRJIrvJAc7qSvbTr8FsmDYnLEoIZph41+NQqlcH2ZGPx7X40J63P YyoBHOYOTX9gmHNA/VTEHiSjMAkqfDoCokkA+TtNdwSAQ7XQ8Xnqn+ainz7jkFeQHJ pYwbZbej84asMJf8QZYJoHA4qkVXSlc86i0KdL/9WtFS6j+cS/uPnogJvdhb57FFaa ncbLEskw8Zvq6H5rU/tvwllCBKgkSxgTs6phYAERq4Tric0O8YcbdOy2PhXmK1vAaU 8xqkR5i74LM4g== Received: by mail-ot1-f45.google.com with SMTP id y10-20020a9d634a000000b006167f7ce0c5so4045900otk.0 for ; Thu, 23 Jun 2022 04:00:55 -0700 (PDT) X-Gm-Message-State: AJIora9gP9EEf0F1M3h7Sjsd+PeSfNSY4AfIOEPo/sqqzYmixQuWR76L Cd7FBGZg9FRZ4j8BrszPKYDljv10FshFV99FJx8= X-Google-Smtp-Source: AGRyM1uCe7JCGN9173roa2AimuVJnTMriwe16/b60nPU+F3xUP6YVF4lRWrGNU4AIhJPsH5uRjvhkdHKWkXd+FXT2Fg= X-Received: by 2002:a9d:37a3:0:b0:60c:5427:1f56 with SMTP id x32-20020a9d37a3000000b0060c54271f56mr3619514otb.71.1655982054468; Thu, 23 Jun 2022 04:00:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 23 Jun 2022 13:00:42 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 0/5] Handling of multiple PCI To: Nicolas Ojeda Leon Cc: edk2-devel-groups-io , Alexander Graf , Leif Lindholm , Sami Mujawar , Erdem Aktas , James Bottomley , Min Xu , Tom Lendacky , Rebecca Cran , Peter Grehan , Sebastien Boeuf , Anthony Perard , Julien Grall , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" On Wed, 22 Jun 2022 at 17:35, Ard Biesheuvel wrote: > > On Tue, 21 Jun 2022 at 23:28, Nicolas Ojeda Leon 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/