2021-01-19 02:12:52 +01:00
|
|
|
/** @file
|
|
|
|
Provide common utility functions to PciHostBridgeLib instances in
|
|
|
|
ArmVirtPkg and OvmfPkg.
|
|
|
|
|
|
|
|
Copyright (C) 2016, Red Hat, Inc.
|
|
|
|
Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
|
|
|
|
Copyright (c) 2020, Huawei Corporation. All rights reserved.<BR>
|
|
|
|
|
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
#include <IndustryStandard/Acpi10.h>
|
2021-01-19 02:12:58 +01:00
|
|
|
#include <IndustryStandard/Pci.h>
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
#include <Library/BaseLib.h>
|
2021-01-19 02:12:55 +01:00
|
|
|
#include <Library/BaseMemoryLib.h>
|
2021-01-19 02:12:52 +01:00
|
|
|
#include <Library/DebugLib.h>
|
2021-01-19 02:12:55 +01:00
|
|
|
#include <Library/DevicePathLib.h>
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
#include <Library/HardwareInfoLib.h>
|
2021-01-19 02:12:55 +01:00
|
|
|
#include <Library/MemoryAllocationLib.h>
|
2021-01-19 02:12:52 +01:00
|
|
|
#include <Library/PciHostBridgeUtilityLib.h>
|
2021-01-19 02:12:58 +01:00
|
|
|
#include <Library/PciLib.h>
|
|
|
|
#include <Library/QemuFwCfgLib.h>
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
#include <Protocol/PciHostBridgeResourceAllocation.h>
|
2021-01-19 02:12:52 +01:00
|
|
|
|
2021-01-19 02:12:55 +01:00
|
|
|
#pragma pack(1)
|
|
|
|
typedef struct {
|
|
|
|
ACPI_HID_DEVICE_PATH AcpiDevicePath;
|
|
|
|
EFI_DEVICE_PATH_PROTOCOL EndDevicePath;
|
|
|
|
} OVMF_PCI_ROOT_BRIDGE_DEVICE_PATH;
|
|
|
|
#pragma pack ()
|
|
|
|
|
2021-01-19 02:12:52 +01:00
|
|
|
GLOBAL_REMOVE_IF_UNREFERENCED
|
|
|
|
CHAR16 *mPciHostBridgeUtilityLibAcpiAddressSpaceTypeStr[] = {
|
|
|
|
L"Mem", L"I/O", L"Bus"
|
|
|
|
};
|
|
|
|
|
2021-01-19 02:12:55 +01:00
|
|
|
STATIC
|
|
|
|
CONST
|
|
|
|
OVMF_PCI_ROOT_BRIDGE_DEVICE_PATH mRootBridgeDevicePathTemplate = {
|
|
|
|
{
|
|
|
|
{
|
|
|
|
ACPI_DEVICE_PATH,
|
|
|
|
ACPI_DP,
|
|
|
|
{
|
|
|
|
(UINT8)(sizeof (ACPI_HID_DEVICE_PATH)),
|
|
|
|
(UINT8)((sizeof (ACPI_HID_DEVICE_PATH)) >> 8)
|
|
|
|
}
|
|
|
|
},
|
|
|
|
EISA_PNP_ID (0x0A03), // HID
|
|
|
|
0 // UID
|
|
|
|
},
|
|
|
|
|
|
|
|
{
|
|
|
|
END_DEVICE_PATH_TYPE,
|
|
|
|
END_ENTIRE_DEVICE_PATH_SUBTYPE,
|
|
|
|
{
|
|
|
|
END_DEVICE_PATH_LENGTH,
|
|
|
|
0
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
Utility function to initialize a PCI_ROOT_BRIDGE structure.
|
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] Supports Supported attributes.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] Attributes Initial attributes.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] AllocAttributes Allocation attributes.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] DmaAbove4G DMA above 4GB memory.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] NoExtendedConfigSpace No Extended Config Space.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] RootBusNumber The bus number to store in RootBus.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] MaxSubBusNumber The inclusive maximum bus number that can
|
|
|
|
be assigned to any subordinate bus found
|
|
|
|
behind any PCI bridge hanging off this
|
|
|
|
root bus.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
The caller is repsonsible for ensuring
|
|
|
|
that RootBusNumber <= MaxSubBusNumber. If
|
|
|
|
RootBusNumber equals MaxSubBusNumber, then
|
|
|
|
the root bus has no room for subordinate
|
|
|
|
buses.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] Io IO aperture.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] Mem MMIO aperture.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] MemAbove4G MMIO aperture above 4G.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] PMem Prefetchable MMIO aperture.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[in] PMemAbove4G Prefetchable MMIO aperture above 4G.
|
2021-01-19 02:12:55 +01:00
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
@param[out] RootBus The PCI_ROOT_BRIDGE structure (allocated
|
|
|
|
by the caller) that should be filled in by
|
|
|
|
this function.
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS Initialization successful. A device path
|
|
|
|
consisting of an ACPI device path node,
|
|
|
|
with UID = RootBusNumber, has been
|
|
|
|
allocated and linked into RootBus.
|
|
|
|
|
|
|
|
@retval EFI_OUT_OF_RESOURCES Memory allocation failed.
|
2021-01-19 02:12:55 +01:00
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
PciHostBridgeUtilityInitRootBridge (
|
|
|
|
IN UINT64 Supports,
|
|
|
|
IN UINT64 Attributes,
|
|
|
|
IN UINT64 AllocAttributes,
|
2021-01-19 02:12:56 +01:00
|
|
|
IN BOOLEAN DmaAbove4G,
|
|
|
|
IN BOOLEAN NoExtendedConfigSpace,
|
2021-01-19 02:12:55 +01:00
|
|
|
IN UINT8 RootBusNumber,
|
|
|
|
IN UINT8 MaxSubBusNumber,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *Io,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *Mem,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *MemAbove4G,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *PMem,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *PMemAbove4G,
|
|
|
|
OUT PCI_ROOT_BRIDGE *RootBus
|
|
|
|
)
|
|
|
|
{
|
|
|
|
OVMF_PCI_ROOT_BRIDGE_DEVICE_PATH *DevicePath;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Be safe if other fields are added to PCI_ROOT_BRIDGE later.
|
|
|
|
//
|
|
|
|
ZeroMem (RootBus, sizeof *RootBus);
|
|
|
|
|
|
|
|
RootBus->Segment = 0;
|
|
|
|
|
|
|
|
RootBus->Supports = Supports;
|
|
|
|
RootBus->Attributes = Attributes;
|
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
RootBus->DmaAbove4G = DmaAbove4G;
|
2021-01-19 02:12:55 +01:00
|
|
|
|
|
|
|
RootBus->AllocationAttributes = AllocAttributes;
|
|
|
|
RootBus->Bus.Base = RootBusNumber;
|
|
|
|
RootBus->Bus.Limit = MaxSubBusNumber;
|
|
|
|
CopyMem (&RootBus->Io, Io, sizeof (*Io));
|
|
|
|
CopyMem (&RootBus->Mem, Mem, sizeof (*Mem));
|
|
|
|
CopyMem (&RootBus->MemAbove4G, MemAbove4G, sizeof (*MemAbove4G));
|
|
|
|
CopyMem (&RootBus->PMem, PMem, sizeof (*PMem));
|
|
|
|
CopyMem (&RootBus->PMemAbove4G, PMemAbove4G, sizeof (*PMemAbove4G));
|
|
|
|
|
2021-01-19 02:12:56 +01:00
|
|
|
RootBus->NoExtendedConfigSpace = NoExtendedConfigSpace;
|
2021-01-19 02:12:55 +01:00
|
|
|
|
|
|
|
DevicePath = AllocateCopyPool (
|
|
|
|
sizeof mRootBridgeDevicePathTemplate,
|
|
|
|
&mRootBridgeDevicePathTemplate
|
|
|
|
);
|
|
|
|
if (DevicePath == NULL) {
|
2023-04-06 21:49:41 +02:00
|
|
|
DEBUG ((DEBUG_ERROR, "%a: %r\n", __func__, EFI_OUT_OF_RESOURCES));
|
2021-01-19 02:12:55 +01:00
|
|
|
return EFI_OUT_OF_RESOURCES;
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:55 +01:00
|
|
|
DevicePath->AcpiDevicePath.UID = RootBusNumber;
|
|
|
|
RootBus->DevicePath = (EFI_DEVICE_PATH_PROTOCOL *)DevicePath;
|
|
|
|
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_INFO,
|
|
|
|
"%a: populated root bus %d, with room for %d subordinate bus(es)\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__,
|
2021-01-19 02:12:55 +01:00
|
|
|
RootBusNumber,
|
|
|
|
MaxSubBusNumber - RootBusNumber
|
|
|
|
));
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Utility function to uninitialize a PCI_ROOT_BRIDGE structure set up with
|
|
|
|
PciHostBridgeUtilityInitRootBridge().
|
|
|
|
|
|
|
|
@param[in] RootBus The PCI_ROOT_BRIDGE structure, allocated by the caller and
|
|
|
|
initialized with PciHostBridgeUtilityInitRootBridge(),
|
|
|
|
that should be uninitialized. This function doesn't free
|
|
|
|
RootBus.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
PciHostBridgeUtilityUninitRootBridge (
|
|
|
|
IN PCI_ROOT_BRIDGE *RootBus
|
|
|
|
)
|
|
|
|
{
|
|
|
|
FreePool (RootBus->DevicePath);
|
|
|
|
}
|
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
/**
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
Utility function to scan PCI root bridges and create instances for those
|
|
|
|
that are found not empty. Populate their resources from the default
|
|
|
|
provided parameters and return all the root bridge instances in an array.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[out] Count The number of root bridge instances.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] Attributes Initial attributes.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] AllocAttributes Allocation attributes.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] DmaAbove4G DMA above 4GB memory.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] NoExtendedConfigSpace No Extended Config Space.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:13:00 +01:00
|
|
|
@param[in] BusMin Minimum Bus number, inclusive.
|
|
|
|
|
|
|
|
@param[in] BusMax Maximum Bus number, inclusive.
|
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] Io IO aperture.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] Mem MMIO aperture.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] MemAbove4G MMIO aperture above 4G.
|
2021-01-19 02:12:58 +01:00
|
|
|
|
2021-01-19 02:12:59 +01:00
|
|
|
@param[in] PMem Prefetchable MMIO aperture.
|
|
|
|
|
|
|
|
@param[in] PMemAbove4G Prefetchable MMIO aperture above 4G.
|
|
|
|
|
|
|
|
@return All the root bridge instances in an array.
|
2021-01-19 02:12:58 +01:00
|
|
|
**/
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
STATIC
|
2021-01-19 02:12:58 +01:00
|
|
|
PCI_ROOT_BRIDGE *
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
PciHostBridgeUtilityGetRootBridgesBusScan (
|
2021-01-19 02:12:58 +01:00
|
|
|
OUT UINTN *Count,
|
|
|
|
IN UINT64 Attributes,
|
|
|
|
IN UINT64 AllocationAttributes,
|
2021-01-19 02:12:59 +01:00
|
|
|
IN BOOLEAN DmaAbove4G,
|
|
|
|
IN BOOLEAN NoExtendedConfigSpace,
|
2021-01-19 02:13:00 +01:00
|
|
|
IN UINTN BusMin,
|
|
|
|
IN UINTN BusMax,
|
2021-01-19 02:12:58 +01:00
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *Io,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *Mem,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *MemAbove4G,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *PMem,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *PMemAbove4G
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
FIRMWARE_CONFIG_ITEM FwCfgItem;
|
|
|
|
UINTN FwCfgSize;
|
|
|
|
UINT64 ExtraRootBridges;
|
|
|
|
PCI_ROOT_BRIDGE *Bridges;
|
|
|
|
UINTN Initialized;
|
|
|
|
UINTN LastRootBridgeNumber;
|
|
|
|
UINTN RootBridgeNumber;
|
|
|
|
|
2021-01-19 02:13:00 +01:00
|
|
|
if ((BusMin > BusMax) || (BusMax > PCI_MAX_BUS)) {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
"%a: invalid bus range with BusMin %Lu and BusMax "
|
|
|
|
"%Lu\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__,
|
2021-01-19 02:13:00 +01:00
|
|
|
(UINT64)BusMin,
|
|
|
|
(UINT64)BusMax
|
|
|
|
));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
//
|
|
|
|
// QEMU provides the number of extra root buses, shortening the exhaustive
|
|
|
|
// search below. If there is no hint, the feature is missing.
|
|
|
|
//
|
|
|
|
Status = QemuFwCfgFindFile ("etc/extra-pci-roots", &FwCfgItem, &FwCfgSize);
|
|
|
|
if (EFI_ERROR (Status) || (FwCfgSize != sizeof ExtraRootBridges)) {
|
|
|
|
ExtraRootBridges = 0;
|
|
|
|
} else {
|
|
|
|
QemuFwCfgSelectItem (FwCfgItem);
|
|
|
|
QemuFwCfgReadBytes (FwCfgSize, &ExtraRootBridges);
|
|
|
|
|
2021-01-19 02:13:00 +01:00
|
|
|
//
|
|
|
|
// Validate the number of extra root bridges. As BusMax is inclusive, the
|
|
|
|
// max bus count is (BusMax - BusMin + 1). From that, the "main" root bus
|
|
|
|
// is always a given, so the max count for the "extra" root bridges is one
|
|
|
|
// less, i.e. (BusMax - BusMin). If the QEMU hint exceeds that, we have
|
|
|
|
// invalid behavior.
|
|
|
|
//
|
|
|
|
if (ExtraRootBridges > BusMax - BusMin) {
|
2021-01-19 02:12:58 +01:00
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
"%a: invalid count of extra root buses (%Lu) "
|
|
|
|
"reported by QEMU\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__,
|
2021-01-19 02:12:58 +01:00
|
|
|
ExtraRootBridges
|
|
|
|
));
|
|
|
|
return NULL;
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
DEBUG ((
|
|
|
|
DEBUG_INFO,
|
|
|
|
"%a: %Lu extra root buses reported by QEMU\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__,
|
2021-01-19 02:12:58 +01:00
|
|
|
ExtraRootBridges
|
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Allocate the "main" root bridge, and any extra root bridges.
|
|
|
|
//
|
|
|
|
Bridges = AllocatePool ((1 + (UINTN)ExtraRootBridges) * sizeof *Bridges);
|
|
|
|
if (Bridges == NULL) {
|
2023-04-06 21:49:41 +02:00
|
|
|
DEBUG ((DEBUG_ERROR, "%a: %r\n", __func__, EFI_OUT_OF_RESOURCES));
|
2021-01-19 02:12:58 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
Initialized = 0;
|
|
|
|
|
|
|
|
//
|
|
|
|
// The "main" root bus is always there.
|
|
|
|
//
|
2021-01-19 02:13:00 +01:00
|
|
|
LastRootBridgeNumber = BusMin;
|
2021-01-19 02:12:58 +01:00
|
|
|
|
|
|
|
//
|
|
|
|
// Scan all other root buses. If function 0 of any device on a bus returns a
|
|
|
|
// VendorId register value different from all-bits-one, then that bus is
|
|
|
|
// alive.
|
|
|
|
//
|
2021-01-19 02:13:00 +01:00
|
|
|
for (RootBridgeNumber = BusMin + 1;
|
|
|
|
RootBridgeNumber <= BusMax && Initialized < ExtraRootBridges;
|
2021-01-19 02:12:58 +01:00
|
|
|
++RootBridgeNumber)
|
|
|
|
{
|
|
|
|
UINTN Device;
|
|
|
|
|
|
|
|
for (Device = 0; Device <= PCI_MAX_DEVICE; ++Device) {
|
|
|
|
if (PciRead16 (
|
|
|
|
PCI_LIB_ADDRESS (
|
|
|
|
RootBridgeNumber,
|
|
|
|
Device,
|
|
|
|
0,
|
|
|
|
PCI_VENDOR_ID_OFFSET
|
2021-12-05 23:54:09 +01:00
|
|
|
)
|
2021-01-19 02:12:58 +01:00
|
|
|
) != MAX_UINT16)
|
|
|
|
{
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
if (Device <= PCI_MAX_DEVICE) {
|
|
|
|
//
|
|
|
|
// Found the next root bus. We can now install the *previous* one,
|
|
|
|
// because now we know how big a bus number range *that* one has, for any
|
|
|
|
// subordinate buses that might exist behind PCI bridges hanging off it.
|
|
|
|
//
|
|
|
|
Status = PciHostBridgeUtilityInitRootBridge (
|
|
|
|
Attributes,
|
|
|
|
Attributes,
|
|
|
|
AllocationAttributes,
|
2021-01-19 02:12:59 +01:00
|
|
|
DmaAbove4G,
|
|
|
|
NoExtendedConfigSpace,
|
2021-01-19 02:12:58 +01:00
|
|
|
(UINT8)LastRootBridgeNumber,
|
|
|
|
(UINT8)(RootBridgeNumber - 1),
|
|
|
|
Io,
|
|
|
|
Mem,
|
|
|
|
MemAbove4G,
|
|
|
|
PMem,
|
|
|
|
PMemAbove4G,
|
|
|
|
&Bridges[Initialized]
|
|
|
|
);
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
goto FreeBridges;
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
++Initialized;
|
|
|
|
LastRootBridgeNumber = RootBridgeNumber;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Install the last root bus (which might be the only, ie. main, root bus, if
|
|
|
|
// we've found no extra root buses).
|
|
|
|
//
|
|
|
|
Status = PciHostBridgeUtilityInitRootBridge (
|
|
|
|
Attributes,
|
|
|
|
Attributes,
|
|
|
|
AllocationAttributes,
|
2021-01-19 02:12:59 +01:00
|
|
|
DmaAbove4G,
|
|
|
|
NoExtendedConfigSpace,
|
2021-01-19 02:12:58 +01:00
|
|
|
(UINT8)LastRootBridgeNumber,
|
2021-01-19 02:13:00 +01:00
|
|
|
(UINT8)BusMax,
|
2021-01-19 02:12:58 +01:00
|
|
|
Io,
|
|
|
|
Mem,
|
|
|
|
MemAbove4G,
|
|
|
|
PMem,
|
|
|
|
PMemAbove4G,
|
|
|
|
&Bridges[Initialized]
|
|
|
|
);
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
goto FreeBridges;
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
++Initialized;
|
|
|
|
|
|
|
|
*Count = Initialized;
|
|
|
|
return Bridges;
|
|
|
|
|
|
|
|
FreeBridges:
|
|
|
|
while (Initialized > 0) {
|
|
|
|
--Initialized;
|
|
|
|
PciHostBridgeUtilityUninitRootBridge (&Bridges[Initialized]);
|
|
|
|
}
|
|
|
|
|
|
|
|
FreePool (Bridges);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
/**
|
|
|
|
Utility function to read root bridges information from host-provided fw-cfg
|
|
|
|
file and return them in an array.
|
|
|
|
|
|
|
|
@param[out] Count The number of root bridge instances.
|
|
|
|
|
|
|
|
@return All the root bridge instances in an array parsed from
|
|
|
|
host-provided fw-cfg file (hardware-info).
|
|
|
|
**/
|
|
|
|
STATIC
|
|
|
|
PCI_ROOT_BRIDGE *
|
|
|
|
PciHostBridgeUtilityGetRootBridgesHostProvided (
|
|
|
|
OUT UINTN *Count
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
FIRMWARE_CONFIG_ITEM FwCfgItem;
|
|
|
|
UINTN FwCfgSize;
|
|
|
|
PCI_ROOT_BRIDGE *Bridges;
|
|
|
|
UINTN Initialized;
|
|
|
|
UINTN LastRootBridgeNumber;
|
|
|
|
UINTN RootBridgeNumber;
|
|
|
|
UINTN PciHostBridgeCount;
|
|
|
|
UINT8 *HardwareInfoBlob;
|
|
|
|
LIST_ENTRY HwInfoList;
|
|
|
|
LIST_ENTRY *HwLink;
|
|
|
|
HARDWARE_INFO *HwInfo;
|
|
|
|
UINT64 Attributes;
|
|
|
|
UINT64 AllocationAttributes;
|
|
|
|
BOOLEAN DmaAbove4G;
|
|
|
|
BOOLEAN NoExtendedConfigSpace;
|
|
|
|
BOOLEAN CombineMemPMem;
|
|
|
|
PCI_ROOT_BRIDGE_APERTURE Io;
|
|
|
|
PCI_ROOT_BRIDGE_APERTURE Mem;
|
|
|
|
PCI_ROOT_BRIDGE_APERTURE MemAbove4G;
|
|
|
|
PCI_ROOT_BRIDGE_APERTURE PMem;
|
|
|
|
PCI_ROOT_BRIDGE_APERTURE PMemAbove4G;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Initialize the Hardware Info list head to start with an empty but valid
|
|
|
|
// list head.
|
|
|
|
//
|
|
|
|
InitializeListHead (&HwInfoList);
|
|
|
|
HardwareInfoBlob = NULL;
|
|
|
|
Initialized = 0;
|
|
|
|
Bridges = NULL;
|
|
|
|
PciHostBridgeCount = 0;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Hypervisor can provide the specifications (resources) for one or more
|
|
|
|
// PCI host bridges. Such information comes through fw-cfg as part of
|
|
|
|
// the hardware-info file.
|
|
|
|
//
|
|
|
|
Status = QemuFwCfgFindFile ("etc/hardware-info", &FwCfgItem, &FwCfgSize);
|
|
|
|
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
HardwareInfoBlob = AllocatePool (FwCfgSize);
|
|
|
|
|
|
|
|
if (HardwareInfoBlob == NULL) {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
"%a: Failed to allocate memory for hardware resources info\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
QemuFwCfgSelectItem (FwCfgItem);
|
|
|
|
QemuFwCfgReadBytes (FwCfgSize, HardwareInfoBlob);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Create the list of hardware info devices filtering for PCI host
|
|
|
|
// bridges
|
|
|
|
//
|
|
|
|
Status = CreateHardwareInfoList (
|
|
|
|
HardwareInfoBlob,
|
|
|
|
FwCfgSize,
|
|
|
|
HardwareInfoTypeHostBridge,
|
|
|
|
&HwInfoList
|
|
|
|
);
|
|
|
|
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
"%a: Failed to create hardware info list to retrieve host "
|
|
|
|
"bridges information from fw-cfg\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
));
|
|
|
|
|
|
|
|
goto FreeBridges;
|
|
|
|
}
|
|
|
|
|
|
|
|
PciHostBridgeCount = GetHardwareInfoCountByType (
|
|
|
|
&HwInfoList,
|
|
|
|
HardwareInfoTypeHostBridge,
|
|
|
|
sizeof (HOST_BRIDGE_INFO)
|
|
|
|
);
|
|
|
|
|
|
|
|
if (PciHostBridgeCount == 0) {
|
|
|
|
goto FreeBridges;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_INFO,
|
|
|
|
"%a: Host provided description for %Lu root bridges\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__,
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
PciHostBridgeCount
|
|
|
|
));
|
|
|
|
|
|
|
|
//
|
|
|
|
// Allocate the root bridges
|
|
|
|
//
|
|
|
|
Bridges = AllocatePool (((UINTN)PciHostBridgeCount) * sizeof *Bridges);
|
|
|
|
if (Bridges == NULL) {
|
2023-04-06 21:49:41 +02:00
|
|
|
DEBUG ((DEBUG_ERROR, "%a: %r\n", __func__, EFI_OUT_OF_RESOURCES));
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
goto FreeBridges;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// If Host Bridges' specification was obtained from fw-cfg, the list
|
|
|
|
// contains information to populate all root bridges in the system
|
|
|
|
// including resources and attributes.
|
|
|
|
//
|
|
|
|
HwLink = GetFirstHardwareInfoByType (
|
|
|
|
&HwInfoList,
|
|
|
|
HardwareInfoTypeHostBridge,
|
|
|
|
sizeof (HOST_BRIDGE_INFO)
|
|
|
|
);
|
|
|
|
|
|
|
|
while (!EndOfHardwareInfoList (&HwInfoList, HwLink)) {
|
|
|
|
HwInfo = HARDWARE_INFO_FROM_LINK (HwLink);
|
|
|
|
|
|
|
|
Status = HardwareInfoPciHostBridgeGet (
|
|
|
|
HwInfo->Data.PciHostBridge,
|
|
|
|
(UINTN)HwInfo->Header.Size,
|
|
|
|
&RootBridgeNumber,
|
|
|
|
&LastRootBridgeNumber,
|
|
|
|
&Attributes,
|
|
|
|
&DmaAbove4G,
|
|
|
|
&NoExtendedConfigSpace,
|
|
|
|
&CombineMemPMem,
|
|
|
|
&Io,
|
|
|
|
&Mem,
|
|
|
|
&MemAbove4G,
|
|
|
|
&PMem,
|
|
|
|
&PMemAbove4G,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
goto FreeBridges;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((RootBridgeNumber > LastRootBridgeNumber) || (LastRootBridgeNumber > PCI_MAX_BUS)) {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
"%a: invalid bus range with BusMin %Lu and BusMax "
|
|
|
|
"%Lu\n",
|
2023-04-06 21:49:41 +02:00
|
|
|
__func__,
|
OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
2021-06-29 17:52:13 +02:00
|
|
|
(UINT64)RootBridgeNumber,
|
|
|
|
(UINT64)LastRootBridgeNumber
|
|
|
|
));
|
|
|
|
goto FreeBridges;
|
|
|
|
}
|
|
|
|
|
|
|
|
AllocationAttributes = 0;
|
|
|
|
if (CombineMemPMem) {
|
|
|
|
AllocationAttributes |= EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((MemAbove4G.Limit > MemAbove4G.Base) ||
|
|
|
|
(PMemAbove4G.Limit > PMemAbove4G.Base))
|
|
|
|
{
|
|
|
|
AllocationAttributes |= EFI_PCI_HOST_BRIDGE_MEM64_DECODE;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status = PciHostBridgeUtilityInitRootBridge (
|
|
|
|
Attributes,
|
|
|
|
Attributes,
|
|
|
|
AllocationAttributes,
|
|
|
|
DmaAbove4G,
|
|
|
|
NoExtendedConfigSpace,
|
|
|
|
(UINT8)RootBridgeNumber,
|
|
|
|
(UINT8)LastRootBridgeNumber,
|
|
|
|
&Io,
|
|
|
|
&Mem,
|
|
|
|
&MemAbove4G,
|
|
|
|
&PMem,
|
|
|
|
&PMemAbove4G,
|
|
|
|
&Bridges[Initialized]
|
|
|
|
);
|
|
|
|
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
goto FreeBridges;
|
|
|
|
}
|
|
|
|
|
|
|
|
++Initialized;
|
|
|
|
|
|
|
|
HwLink = GetNextHardwareInfoByType (
|
|
|
|
&HwInfoList,
|
|
|
|
HwLink,
|
|
|
|
HardwareInfoTypeHostBridge,
|
|
|
|
sizeof (HOST_BRIDGE_INFO)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
*Count = Initialized;
|
|
|
|
|
|
|
|
//
|
|
|
|
// If resources were allocated for host bridges info, release them
|
|
|
|
//
|
|
|
|
if (HardwareInfoBlob) {
|
|
|
|
FreePool (HardwareInfoBlob);
|
|
|
|
}
|
|
|
|
|
|
|
|
FreeHardwareInfoList (&HwInfoList);
|
|
|
|
return Bridges;
|
|
|
|
|
|
|
|
FreeBridges:
|
|
|
|
while (Initialized > 0) {
|
|
|
|
--Initialized;
|
|
|
|
PciHostBridgeUtilityUninitRootBridge (&Bridges[Initialized]);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Bridges) {
|
|
|
|
FreePool (Bridges);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (HardwareInfoBlob) {
|
|
|
|
FreePool (HardwareInfoBlob);
|
|
|
|
}
|
|
|
|
|
|
|
|
FreeHardwareInfoList (&HwInfoList);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Utility function to return all the root bridge instances in an array.
|
|
|
|
|
|
|
|
@param[out] Count The number of root bridge instances.
|
|
|
|
|
|
|
|
@param[in] Attributes Initial attributes.
|
|
|
|
|
|
|
|
@param[in] AllocAttributes Allocation attributes.
|
|
|
|
|
|
|
|
@param[in] DmaAbove4G DMA above 4GB memory.
|
|
|
|
|
|
|
|
@param[in] NoExtendedConfigSpace No Extended Config Space.
|
|
|
|
|
|
|
|
@param[in] BusMin Minimum Bus number, inclusive.
|
|
|
|
|
|
|
|
@param[in] BusMax Maximum Bus number, inclusive.
|
|
|
|
|
|
|
|
@param[in] Io IO aperture.
|
|
|
|
|
|
|
|
@param[in] Mem MMIO aperture.
|
|
|
|
|
|
|
|
@param[in] MemAbove4G MMIO aperture above 4G.
|
|
|
|
|
|
|
|
@param[in] PMem Prefetchable MMIO aperture.
|
|
|
|
|
|
|
|
@param[in] PMemAbove4G Prefetchable MMIO aperture above 4G.
|
|
|
|
|
|
|
|
@return All the root bridge instances in an array.
|
|
|
|
**/
|
|
|
|
PCI_ROOT_BRIDGE *
|
|
|
|
EFIAPI
|
|
|
|
PciHostBridgeUtilityGetRootBridges (
|
|
|
|
OUT UINTN *Count,
|
|
|
|
IN UINT64 Attributes,
|
|
|
|
IN UINT64 AllocationAttributes,
|
|
|
|
IN BOOLEAN DmaAbove4G,
|
|
|
|
IN BOOLEAN NoExtendedConfigSpace,
|
|
|
|
IN UINTN BusMin,
|
|
|
|
IN UINTN BusMax,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *Io,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *Mem,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *MemAbove4G,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *PMem,
|
|
|
|
IN PCI_ROOT_BRIDGE_APERTURE *PMemAbove4G
|
|
|
|
)
|
|
|
|
{
|
|
|
|
PCI_ROOT_BRIDGE *Bridges;
|
|
|
|
|
|
|
|
*Count = 0;
|
|
|
|
|
|
|
|
//
|
|
|
|
// First attempt to get the host provided descriptions of the Root Bridges
|
|
|
|
// if available.
|
|
|
|
//
|
|
|
|
Bridges = PciHostBridgeUtilityGetRootBridgesHostProvided (Count);
|
|
|
|
|
|
|
|
//
|
|
|
|
// If host did not provide Root Bridge information, scan the buses and
|
|
|
|
// auto populate them with default resources.
|
|
|
|
//
|
|
|
|
if (Bridges == NULL) {
|
|
|
|
Bridges = PciHostBridgeUtilityGetRootBridgesBusScan (
|
|
|
|
Count,
|
|
|
|
Attributes,
|
|
|
|
AllocationAttributes,
|
|
|
|
DmaAbove4G,
|
|
|
|
NoExtendedConfigSpace,
|
|
|
|
BusMin,
|
|
|
|
BusMax,
|
|
|
|
Io,
|
|
|
|
Mem,
|
|
|
|
MemAbove4G,
|
|
|
|
PMem,
|
|
|
|
PMemAbove4G
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Bridges;
|
|
|
|
}
|
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
/**
|
|
|
|
Utility function to free root bridge instances array from
|
|
|
|
PciHostBridgeUtilityGetRootBridges().
|
|
|
|
|
|
|
|
@param[in] Bridges The root bridge instances array.
|
|
|
|
@param[in] Count The count of the array.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
PciHostBridgeUtilityFreeRootBridges (
|
|
|
|
IN PCI_ROOT_BRIDGE *Bridges,
|
|
|
|
IN UINTN Count
|
|
|
|
)
|
|
|
|
{
|
|
|
|
if ((Bridges == NULL) && (Count == 0)) {
|
|
|
|
return;
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:58 +01:00
|
|
|
ASSERT (Bridges != NULL && Count > 0);
|
|
|
|
|
|
|
|
do {
|
|
|
|
--Count;
|
|
|
|
PciHostBridgeUtilityUninitRootBridge (&Bridges[Count]);
|
|
|
|
} while (Count > 0);
|
|
|
|
|
|
|
|
FreePool (Bridges);
|
|
|
|
}
|
|
|
|
|
2021-01-19 02:12:52 +01:00
|
|
|
/**
|
|
|
|
Utility function to inform the platform that the resource conflict happens.
|
|
|
|
|
|
|
|
@param[in] Configuration Pointer to PCI I/O and PCI memory resource
|
|
|
|
descriptors. The Configuration contains the
|
|
|
|
resources for all the root bridges. The resource
|
|
|
|
for each root bridge is terminated with END
|
|
|
|
descriptor and an additional END is appended
|
|
|
|
indicating the end of the entire resources. The
|
|
|
|
resource descriptor field values follow the
|
|
|
|
description in
|
|
|
|
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL
|
|
|
|
.SubmitResources().
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
PciHostBridgeUtilityResourceConflict (
|
|
|
|
IN VOID *Configuration
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor;
|
|
|
|
UINTN RootBridgeIndex;
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:52 +01:00
|
|
|
DEBUG ((DEBUG_ERROR, "PciHostBridge: Resource conflict happens!\n"));
|
|
|
|
|
|
|
|
RootBridgeIndex = 0;
|
|
|
|
Descriptor = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *)Configuration;
|
|
|
|
while (Descriptor->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
|
|
|
|
DEBUG ((DEBUG_ERROR, "RootBridge[%d]:\n", RootBridgeIndex++));
|
|
|
|
for ( ; Descriptor->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR; Descriptor++) {
|
|
|
|
ASSERT (
|
|
|
|
Descriptor->ResType <
|
|
|
|
ARRAY_SIZE (mPciHostBridgeUtilityLibAcpiAddressSpaceTypeStr)
|
|
|
|
);
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
" %s: Length/Alignment = 0x%lx / 0x%lx\n",
|
|
|
|
mPciHostBridgeUtilityLibAcpiAddressSpaceTypeStr[Descriptor->ResType],
|
|
|
|
Descriptor->AddrLen,
|
|
|
|
Descriptor->AddrRangeMax
|
|
|
|
));
|
|
|
|
if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
" Granularity/SpecificFlag = %ld / %02x%s\n",
|
|
|
|
Descriptor->AddrSpaceGranularity,
|
|
|
|
Descriptor->SpecificFlag,
|
|
|
|
((Descriptor->SpecificFlag &
|
|
|
|
EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE
|
|
|
|
) != 0) ? L" (Prefetchable)" : L""
|
|
|
|
));
|
|
|
|
}
|
|
|
|
}
|
2021-12-05 23:54:09 +01:00
|
|
|
|
2021-01-19 02:12:52 +01:00
|
|
|
//
|
|
|
|
// Skip the END descriptor for root bridge
|
|
|
|
//
|
|
|
|
ASSERT (Descriptor->Desc == ACPI_END_TAG_DESCRIPTOR);
|
|
|
|
Descriptor = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *)(
|
|
|
|
(EFI_ACPI_END_TAG_DESCRIPTOR *)Descriptor + 1
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|