public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Nicolas Ojeda Leon <ncoleon@amazon.com>
To: <devel@edk2.groups.io>
Cc: Nicolas Ojeda Leon <ncoleon@amazon.com>
Subject: [PATCH 0/5] Handling of multiple PCI host bridges with pre-populated resources in Ovmf.
Date: Sat, 4 Sep 2021 16:37:51 +0200	[thread overview]
Message-ID: <cover.1630676569.git.ncoleon@amazon.com> (raw)

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 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 platforms supports a single host bridges and EDK2 contains the
logic to determine its MMIO resources. However, we need a way to define
more than 1 host bridge and control, from the hypervisor, how many and
which resources each of them can use. For this reason, this patch series
introduces a mechanism to provide bus number, pxm number, bus number
ranges 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.

Furthermore, in these kind of high performance platforms, we exploit
PCIe features like Access Control Services to configure peer-to-peer
channels between devices. This allows us to create direct communication
channels that do not require packets to reach the Root Complex but
instead can follow a direct path from source to target. To enable Guest
Virtual Machines to profit from this performance improvement, we
configure resources (BARs) of peer-to-peer intended devices with Host
Physical Addresses. In this scenario, devices can be instructed, from
the guest VM, to perform DMA operations targeting a peer address space,
and the PCIe fabric can take care of directly routing them. Therefore
long and busy links towards the Root Complex are avoided. When we
configure resources this way, the guest must respect the pre-populated
BARs so that devices preserve the address ranges configured in the
apertures of physical PCIe ports that enable routing at the hardware
level.

Nicolas Ojeda Leon (5):
  OvmfPkg/PlatformPei: Extend 64-bit PCI range for multiple host bridges
  OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with
    spec
  MdeModulePkg OvmfPkg: Add Pcd token for PCI pre-populated BARs
  MdeModulePkg/Pci MdePkg: Create service to retrieve PCI base addresses
  MdeModulePkg/PciBusDxe: Handling of pre-populated PCI BARs

 MdeModulePkg/MdeModulePkg.dec                 |   6 +
 OvmfPkg/OvmfPkgX64.dsc                        |   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |   1 +
 .../PciHostBridgeUtilityLib.inf               |   4 +
 OvmfPkg/PlatformPei/PlatformPei.inf           |   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |   1 +
 .../Bus/Pci/PciBusDxe/PciResourceSupport.h    |  20 ++
 .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.h  |  29 ++
 .../PciHostBridgeResourceAllocation.h         |  33 ++
 .../Include/Library/PciHostBridgeInfoLib.h    |  43 +++
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  |   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c       |  21 ++
 .../Bus/Pci/PciBusDxe/PciResourceSupport.c    | 281 +++++++++++++++++-
 .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c  |  80 +++++
 .../PciHostBridgeUtilityLib.c                 | 145 ++++++++-
 OvmfPkg/PlatformPei/MemDetect.c               |  83 ++++++
 16 files changed, 746 insertions(+), 4 deletions(-)
 create mode 100644 OvmfPkg/Include/Library/PciHostBridgeInfoLib.h

-- 
2.17.1




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:[~2021-09-04 14:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-04 14:37 Nicolas Ojeda Leon [this message]
2021-09-04 14:37 ` [PATCH 1/5] OvmfPkg/PlatformPei: Extend 64-bit PCI range for multiple host bridges Nicolas Ojeda Leon
2021-09-08  8:03   ` [edk2-devel] " Gerd Hoffmann
2021-09-04 14:37 ` [PATCH 2/5] OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec Nicolas Ojeda Leon
2021-09-04 14:37 ` [PATCH 3/5] MdeModulePkg OvmfPkg: Add Pcd token for PCI pre-populated BARs Nicolas Ojeda Leon
2021-09-04 14:37 ` [PATCH 4/5] MdeModulePkg/Pci MdePkg: Create service to retrieve PCI base addresses Nicolas Ojeda Leon
2021-09-04 14:37 ` [PATCH 5/5] MdeModulePkg/PciBusDxe: Handling of pre-populated PCI BARs Nicolas Ojeda Leon

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=cover.1630676569.git.ncoleon@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