public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ojeda Leon, Nicolas" <ncoleon@amazon.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>, "Graf (AWS),
	Alexander" <graf@amazon.de>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Erdem Aktas <erdemaktas@google.com>,
	James Bottomley <jejb@linux.ibm.com>, Min Xu <min.m.xu@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Rebecca Cran <rebecca@bsdio.com>,
	Peter Grehan <grehan@freebsd.org>,
	Sebastien Boeuf <sebastien.boeuf@intel.com>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	Julien Grall <julien@xen.org>,
	"Ard Biesheuvel" <ardb+tianocore@kernel.org>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH v6 0/5] Handling of multiple PCI
Date: Thu, 23 Jun 2022 14:14:38 +0000	[thread overview]
Message-ID: <f9788a0820fe44adaa07a558859226b9@EX13D49EUC003.ant.amazon.com> (raw)
In-Reply-To: <CAMj1kXEV3wMX5C3RH9utb-K3R1UxRENQe3=5bhs7ayq_BqPmew@mail.gmail.com>

> On Wed, 22 Jun 2022 at 17:35, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Tue, 21 Jun 2022 at 23:28, Nicolas Ojeda Leon <ncoleon@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/

Thanks Ard for notifying.

I will post the fix in short, tested build locally and now running the CI pipeline (https://github.com/tianocore/edk2/pull/2938).

Best regards,

Nicolas



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



      reply	other threads:[~2022-06-23 14:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21 21:27 [PATCH v6 0/5] Handling of multiple PCI Ojeda Leon, Nicolas
2022-06-21 21:31 ` [PATCH v6 1/5] OvmfPkg/Library: Create base HardwareInfoLib for PCI Host Bridges Ojeda Leon, Nicolas
2022-06-21 21:34 ` [PATCH v6 2/5] Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfg Ojeda Leon, Nicolas
2022-06-21 21:37 ` [PATCH v6 3/5] Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous data Ojeda Leon, Nicolas
2022-06-21 21:38 ` [PATCH v6 4/5] Ovmf/PlatformPei: Use host-provided GPA end if available Ojeda Leon, Nicolas
2022-06-21 21:40 ` [PATCH v6 5/5] OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec Ojeda Leon, Nicolas
2022-06-22 15:35 ` [PATCH v6 0/5] Handling of multiple PCI Ard Biesheuvel
2022-06-23 11:00   ` Ard Biesheuvel
2022-06-23 14:14     ` Ojeda Leon, Nicolas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f9788a0820fe44adaa07a558859226b9@EX13D49EUC003.ant.amazon.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox