ArmVirtPkg/ArmVirtQemu.dsc | 2 + OvmfPkg/AmdSev/AmdSevX64.dsc | 2 + OvmfPkg/Bhyve/BhyveX64.dsc | 2 + OvmfPkg/CloudHv/CloudHvX64.dsc | 2 + OvmfPkg/Include/Library/HardwareInfoLib.h | 159 ++++++ .../HardwareInfoLib/DxeHardwareInfoLib.inf | 39 ++ .../Library/HardwareInfoLib/HardwareInfoDxe.c | 254 +++++++++ .../HardwareInfoPciHostBridgeLib.c | 508 ++++++++++++++++++ .../HardwareInfoPciHostBridgeLib.h | 256 +++++++++ .../Library/HardwareInfoLib/HardwareInfoPei.c | 79 +++ .../HardwareInfoLib/HardwareInfoTypesLib.h | 59 ++ .../HardwareInfoLib/PeiHardwareInfoLib.inf | 39 ++ .../QemuFwCfgHardwareInfoLib.c | 88 +++ .../PciHostBridgeUtilityLib.c | 332 +++++++++++- .../PciHostBridgeUtilityLib.inf | 1 + OvmfPkg/Library/PlatformInitLib/MemDetect.c | 148 ++++- .../PlatformInitLib/PlatformInitLib.inf | 1 + OvmfPkg/Microvm/MicrovmX64.dsc | 2 + OvmfPkg/OvmfPkg.dec | 4 + OvmfPkg/OvmfPkgIa32.dsc | 2 + OvmfPkg/OvmfPkgIa32X64.dsc | 2 + OvmfPkg/OvmfPkgX64.dsc | 2 + OvmfPkg/OvmfXen.dsc | 2 + 23 files changed, 1973 insertions(+), 12 deletions(-) create mode 100644 OvmfPkg/Include/Library/HardwareInfoLib.h create mode 100644 OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoDxe.c create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.c create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.h create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPei.c create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoTypesLib.h create mode 100644 OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf create mode 100644 OvmfPkg/Library/HardwareInfoLib/QemuFwCfgHardwareInfoLib.c
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 ArmVirtPkg/ArmVirtQemu.dsc | 2 + OvmfPkg/AmdSev/AmdSevX64.dsc | 2 + OvmfPkg/Bhyve/BhyveX64.dsc | 2 + OvmfPkg/CloudHv/CloudHvX64.dsc | 2 + OvmfPkg/Include/Library/HardwareInfoLib.h | 159 ++++++ .../HardwareInfoLib/DxeHardwareInfoLib.inf | 39 ++ .../Library/HardwareInfoLib/HardwareInfoDxe.c | 254 +++++++++ .../HardwareInfoPciHostBridgeLib.c | 508 ++++++++++++++++++ .../HardwareInfoPciHostBridgeLib.h | 256 +++++++++ .../Library/HardwareInfoLib/HardwareInfoPei.c | 79 +++ .../HardwareInfoLib/HardwareInfoTypesLib.h | 59 ++ .../HardwareInfoLib/PeiHardwareInfoLib.inf | 39 ++ .../QemuFwCfgHardwareInfoLib.c | 88 +++ .../PciHostBridgeUtilityLib.c | 332 +++++++++++- .../PciHostBridgeUtilityLib.inf | 1 + OvmfPkg/Library/PlatformInitLib/MemDetect.c | 148 ++++- .../PlatformInitLib/PlatformInitLib.inf | 1 + OvmfPkg/Microvm/MicrovmX64.dsc | 2 + OvmfPkg/OvmfPkg.dec | 4 + OvmfPkg/OvmfPkgIa32.dsc | 2 + OvmfPkg/OvmfPkgIa32X64.dsc | 2 + OvmfPkg/OvmfPkgX64.dsc | 2 + OvmfPkg/OvmfXen.dsc | 2 + 23 files changed, 1973 insertions(+), 12 deletions(-) create mode 100644 OvmfPkg/Include/Library/HardwareInfoLib.h create mode 100644 OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoDxe.c create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.c create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.h create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPei.c create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoTypesLib.h create mode 100644 OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf create mode 100644 OvmfPkg/Library/HardwareInfoLib/QemuFwCfgHardwareInfoLib.c -- 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90656): https://edk2.groups.io/g/devel/message/90656 Mute This Topic: https://groups.io/mt/91909735/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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, > ArmVirtPkg/ArmVirtQemu.dsc | 2 + > OvmfPkg/AmdSev/AmdSevX64.dsc | 2 + > OvmfPkg/Bhyve/BhyveX64.dsc | 2 + > OvmfPkg/CloudHv/CloudHvX64.dsc | 2 + > OvmfPkg/Include/Library/HardwareInfoLib.h | 159 ++++++ > .../HardwareInfoLib/DxeHardwareInfoLib.inf | 39 ++ > .../Library/HardwareInfoLib/HardwareInfoDxe.c | 254 +++++++++ > .../HardwareInfoPciHostBridgeLib.c | 508 ++++++++++++++++++ > .../HardwareInfoPciHostBridgeLib.h | 256 +++++++++ > .../Library/HardwareInfoLib/HardwareInfoPei.c | 79 +++ > .../HardwareInfoLib/HardwareInfoTypesLib.h | 59 ++ > .../HardwareInfoLib/PeiHardwareInfoLib.inf | 39 ++ > .../QemuFwCfgHardwareInfoLib.c | 88 +++ > .../PciHostBridgeUtilityLib.c | 332 +++++++++++- > .../PciHostBridgeUtilityLib.inf | 1 + > OvmfPkg/Library/PlatformInitLib/MemDetect.c | 148 ++++- > .../PlatformInitLib/PlatformInitLib.inf | 1 + > OvmfPkg/Microvm/MicrovmX64.dsc | 2 + > OvmfPkg/OvmfPkg.dec | 4 + > OvmfPkg/OvmfPkgIa32.dsc | 2 + > OvmfPkg/OvmfPkgIa32X64.dsc | 2 + > OvmfPkg/OvmfPkgX64.dsc | 2 + > OvmfPkg/OvmfXen.dsc | 2 + > 23 files changed, 1973 insertions(+), 12 deletions(-) > create mode 100644 OvmfPkg/Include/Library/HardwareInfoLib.h > create mode 100644 OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf > create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoDxe.c > create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.c > create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.h > create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPei.c > create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoTypesLib.h > create mode 100644 OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf > create mode 100644 OvmfPkg/Library/HardwareInfoLib/QemuFwCfgHardwareInfoLib.c > > -- > 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 > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90687): https://edk2.groups.io/g/devel/message/90687 Mute This Topic: https://groups.io/mt/91909735/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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/ -=-=-=-=-=-=-=-=-=-=-=- 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/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90735): https://edk2.groups.io/g/devel/message/90735 Mute This Topic: https://groups.io/mt/91909735/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.