Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: aa1bce0e5eadafa0c6dc5095e7c8b60195ce3547
https://github.com/tianocore/edk2/commit/aa1bce0e5eadafa0c6dc5095e7c8b60195ce3547
Author: Gerd Hoffmann <kra...@redhat.com>
Date: 2022-06-22 (Wed, 22 Jun 2022)
Changed paths:
M OvmfPkg/AmdSev/AmdSevX64.dsc
M OvmfPkg/CloudHv/CloudHvX64.dsc
M OvmfPkg/OvmfPkgIa32.dsc
M OvmfPkg/OvmfPkgIa32X64.dsc
M OvmfPkg/OvmfPkgX64.dsc
M OvmfPkg/OvmfTpmLibs.dsc.inc
R OvmfPkg/OvmfTpmLibsDxe.dsc.inc
R OvmfPkg/OvmfTpmLibsPeim.dsc.inc
Log Message:
-----------
OvmfPkg: reduce the number of dsc include files for tpm libs
We can have multiple [LibraryClasses] sections, so we can place
all TPM-related library configuration to a single include file.
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Ard Biesheuvel <a...@kernel.org>
Commit: 6c9f218bc0d967bea99b139e190a11b703de4d6c
https://github.com/tianocore/edk2/commit/6c9f218bc0d967bea99b139e190a11b703de4d6c
Author: Nicolas Ojeda Leon <ncol...@amazon.com>
Date: 2022-06-22 (Wed, 22 Jun 2022)
Changed paths:
A OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.c
A OvmfPkg/Library/HardwareInfoLib/HardwareInfoPciHostBridgeLib.h
A OvmfPkg/Library/HardwareInfoLib/HardwareInfoTypesLib.h
Log Message:
-----------
OvmfPkg/Library: Create base HardwareInfoLib for PCI Host Bridges
Create the Hardware Info library base together with the specifics to
describe PCI Host Bridges.
The Hardware Info library is intended to be used for disclosing
non-discoverable hardware information from the host to the guest in
Ovmf platforms. Core functionality will provide the possibility to
parse information from a generic BLOB into runtime structures. 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. The first
type of hardware defined will be PCI host bridges, providing the
possibility to define multiple and specify the resources each of them
can use. This enables the guest firmware to configure PCI resources
properly. Having the size of each individual element favors the reuse
of a single interface to convey descriptions of an arbitrary number
of heterogenous hardware elements. Furthermore, flexible access
mechanisms coupled with the size will grant the possibility of
interpreting them in a single run.
Define the base types of the generic Hardware Info library to parse
heterogeneous data. Also provide the specific changes to support
PCI host bridges as the first hardware type supported by the
library.
Additionally, define the HOST_BRIDGE_INFO structure to describe PCI
host bridges along with the functionality to parse such information
into proper structures used by the PCI driver in a centralized manner
and taking care of versioning.
As an example and motivation, the library will be used to define
multiple PCI host bridges for complex platforms that require it.
The first means of transportation that will be used is going to be
fw-cfg, over which a stream of bytes will be transferred and later
parsed by the hardware info library. Accordingly, the PCI driver
will make use of these host bridges definitions to populate the
list of Root Bridges and proceed with the configuration and discovery
of underlying hardware components.
As mentioned before, the binary data to be parsed by the Hardware
Info library should be organized as a sequence of Header-element
pairs in which the header describes the type and size of the associated
element that comes right after it. As an illustration, to provide
inforation of 3 host bridges the data, conceptually, would look
like this:
Header PCI Host Bridge (type and size) # 1
PCI Host Bridge info # 1
Header PCI Host Bridge (type and size) # 2
PCI Host Bridge info # 2
Header PCI Host Bridge (type and size) # 3
PCI Host Bridge info # 3
Cc: Alexander Graf <g...@amazon.de>
Cc: Gerd Hoffmann <kra...@redhat.com>
Acked-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncol...@amazon.com>
Commit: 2b1a5b8c613301311113e1efc6fc65478e2e6365
https://github.com/tianocore/edk2/commit/2b1a5b8c613301311113e1efc6fc65478e2e6365
Author: Nicolas Ojeda Leon <ncol...@amazon.com>
Date: 2022-06-22 (Wed, 22 Jun 2022)
Changed paths:
M ArmVirtPkg/ArmVirtQemu.dsc
M OvmfPkg/AmdSev/AmdSevX64.dsc
M OvmfPkg/Bhyve/BhyveX64.dsc
M OvmfPkg/CloudHv/CloudHvX64.dsc
A OvmfPkg/Include/Library/HardwareInfoLib.h
A OvmfPkg/Library/HardwareInfoLib/HardwareInfoPei.c
A OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
A OvmfPkg/Library/HardwareInfoLib/QemuFwCfgHardwareInfoLib.c
M OvmfPkg/Microvm/MicrovmX64.dsc
M OvmfPkg/OvmfPkg.dec
M OvmfPkg/OvmfPkgIa32.dsc
M OvmfPkg/OvmfPkgIa32X64.dsc
M OvmfPkg/OvmfPkgX64.dsc
M OvmfPkg/OvmfXen.dsc
Log Message:
-----------
Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfg
Define the HardwareInfoLib API and create the PeiHardwareInfoLib
which implements it, specifically for Pei usage, supporting
only static accesses to parse data directly from a fw-cfg file.
All list-like APIs are implemented as unsupported and only a
fw-cfg wrapper to read hardware info elements is provided.
The Hardware Info library is intended to describe non-discoverable
hardware information and share that from the host to the guest in Ovmf
platforms. The QEMU fw-cfg extension for this library provides a first
variation to parse hardware info by reading it directly from a fw-cfg
file. This library offers a wrapper function to the plain
QmeuFwCfgReadBytes which, specifically, parses header-data pairs out
of the binary values in the file. For this purpose, the approach is
incremental, reading the file block by block and outputting the values
only for a specific known hardware type (e.g. PCI host bridges). One
element is returned in each call until the end of the file is reached.
Considering fw-cfg as the first means to transport hardware info from
the host to the guest, this wrapping library offers the possibility
to statically, and in steps, read a specific type of hardware info
elements out of the file. This method reads one hardware element of a
specific type at a time, without the need to pre-allocate memory and
read the whole file or dynamically allocate memory for each new
element found.
As a usage example, the static approach followed by this library
enables early UEFI stages to use and read hardware information
supplied by the host. For instance, in early times of the PEI stage,
hardware information can be parsed out from a fw-cfg file prescinding
from memory services, that may not yet be available, and avoiding
dynamic memory allocations.
Cc: Alexander Graf <g...@amazon.de>
Cc: Gerd Hoffmann <kra...@redhat.com>
Acked-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncol...@amazon.com>
Commit: a1bd79c5144cf39f4dee951974b377f5c1c03ce7
https://github.com/tianocore/edk2/commit/a1bd79c5144cf39f4dee951974b377f5c1c03ce7
Author: Nicolas Ojeda Leon <ncol...@amazon.com>
Date: 2022-06-22 (Wed, 22 Jun 2022)
Changed paths:
M ArmVirtPkg/ArmVirtQemu.dsc
M OvmfPkg/AmdSev/AmdSevX64.dsc
M OvmfPkg/Bhyve/BhyveX64.dsc
M OvmfPkg/CloudHv/CloudHvX64.dsc
A OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
A OvmfPkg/Library/HardwareInfoLib/HardwareInfoDxe.c
M OvmfPkg/Microvm/MicrovmX64.dsc
M OvmfPkg/OvmfPkgIa32.dsc
M OvmfPkg/OvmfPkgIa32X64.dsc
M OvmfPkg/OvmfPkgX64.dsc
M OvmfPkg/OvmfXen.dsc
Log Message:
-----------
Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous data
Following the Hardware Info library, create the DxeHardwareInfoLib
which implements the whole API capable of parsing heterogeneous hardware
information. The list-like API grants callers a flexible and common
pattern to retrieve the data. Moreover, the initial source is a BLOB
which generalizes the host-to-guest transmission mechanism.
The Hardware Info library main objective is to provide a way to
describe non-discoverable hardware so that the host can share the
available resources with the guest in Ovmf platforms. This change
features and embraces the main idea behind the library by providing
an API that parses a BLOB into a linked list to retrieve hardware
data from any source. Additionally, list-like APIs are provided so
that the hardware info list can be traversed conveniently.
Similarly, the capability is provided to filter results by specific
hardware types. However, heterogeneous elements can be added to the
list, increasing the flexibility. This way, a single source, for
example a fw-cfg file, can be used to describe several instances of
multiple types of hardware.
This part of the Hardware Info library makes use of dynamic memory
and is intended for stages in which memory services are available.
A motivation example is the PciHostBridgeLib. This library, part
of the PCI driver populates the list of PCI root bridges during DXE
stage for future steps to discover the resources under them. The
hardware info library can be used to obtain the detailed description
of available host bridges, for instance in the form of a fw-cfg file,
and parse that information into a dynmaic list that allows, first to
verify consistency of the data, and second discover the resources
availabe for each root bridge.
Cc: Alexander Graf <g...@amazon.de>
Cc: Gerd Hoffmann <kra...@redhat.com>
Acked-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncol...@amazon.com>
Commit: 3497fd5c26da3956c4f06eed46a1e3a8fdac9c15
https://github.com/tianocore/edk2/commit/3497fd5c26da3956c4f06eed46a1e3a8fdac9c15
Author: Nicolas Ojeda Leon <ncol...@amazon.com>
Date: 2022-06-22 (Wed, 22 Jun 2022)
Changed paths:
M OvmfPkg/Library/PlatformInitLib/MemDetect.c
M OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
Log Message:
-----------
Ovmf/PlatformPei: Use host-provided GPA end if available
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate size of physical addresses.
Using the static PeiHardwareInfoLib, read the fw-cfg file of
hardware information to extract, one by one, all the host
bridges. Find the last 64-bit MMIO address of each host bridge,
using the HardwareInfoPciHostBridgeLib API, and compare it to an
accumulate value to discover the highest address used, which
corresponds to the highest value that must be included in the
guest's physical address space.
Given that platforms with multiple host bridges may provide the PCI
apertures' addresses, the memory detection logic must take into
account that, if the host provided the MMIO windows that can and must
be used, the guest needs to take those values. Therefore, if the
MMIO windows are found in the host-provided fw-cfg file, skip all the
logic calculating the physical address size and just use the value
provided. Since each PCI host bridge corresponds to an element in
the information provided by the host, each of these must be analyzed
looking for the highest address used.
Cc: Alexander Graf <g...@amazon.de>
Cc: Gerd Hoffmann <kra...@redhat.com>
Acked-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncol...@amazon.com>
Commit: 3f5b1b9132ffc4bc91ed3bc2da86afe5f78883e7
https://github.com/tianocore/edk2/commit/3f5b1b9132ffc4bc91ed3bc2da86afe5f78883e7
Author: Nicolas Ojeda Leon <ncol...@amazon.com>
Date: 2022-06-22 (Wed, 22 Jun 2022)
Changed paths:
M OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c
M OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.inf
Log Message:
-----------
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 <g...@amazon.de>
Cc: Gerd Hoffmann <kra...@redhat.com>
Acked-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncol...@amazon.com>
Compare: https://github.com/tianocore/edk2/compare/3930d1791a06...3f5b1b9132ff
_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits
