On Mon, Nov 04, 2024 at 04:06:16PM -0500, Michael S. Tsirkin wrote:
> From: Jonathan Cameron <jonathan.came...@huawei.com>
>
> These are very similar to the recently added Generic Initiators
> but instead of representing an initiator of memory traffic they
> represent an edge point beyond which may lie either targets or
> initiators. Here we add these ports such that they may
> be targets of hmat_lb records to describe the latency and
> bandwidth from host side initiators to the port. A discoverable
> mechanism such as UEFI CDAT read from CXL devices and switches
> is used to discover the remainder of the path, and the OS can build
> up full latency and bandwidth numbers as need for work and data
> placement decisions.
>
> Acked-by: Markus Armbruster <arm...@redhat.com>
> Tested-by: "Huang, Ying" <ying.hu...@intel.com>
> Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com>
> Message-Id: <20240916174122.1843197-1-jonathan.came...@huawei.com>
> Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> ---
> qapi/qom.json | 41 ++++++++++
> include/hw/acpi/aml-build.h | 3 +
> include/hw/acpi/pci.h | 2 +-
> include/hw/pci/pci_bridge.h | 1 +
> hw/acpi/aml-build.c | 39 ++++++++++
> hw/acpi/pci.c | 116 +++++++++++++++++++++++++++-
> hw/arm/virt-acpi-build.c | 2 +-
> hw/i386/acpi-build.c | 2 +-
> hw/pci-bridge/pci_expander_bridge.c | 1 -
> 9 files changed, 202 insertions(+), 5 deletions(-)
>
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 321ccd708a..a8beeabf1f 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -844,6 +844,45 @@
> 'data': { 'pci-dev': 'str',
> 'node': 'uint32' } }
>
> +##
> +# @AcpiGenericPortProperties:
> +#
> +# Properties for acpi-generic-port objects.
> +#
> +# @pci-bus: QOM path of the PCI bus of the hostbridge associated with
> +# this SRAT Generic Port Affinity Structure. This is the same as
> +# the bus parameter for the root ports attached to this host
> +# bridge. The resulting SRAT Generic Port Affinity Structure will
> +# refer to the ACPI object in DSDT that represents the host bridge
> +# (e.g. ACPI0016 for CXL host bridges). See ACPI 6.5 Section
> +# 5.2.16.7 for more information.
> +#
> +# @node: Similar to a NUMA node ID, but instead of providing a
> +# reference point used for defining NUMA distances and access
> +# characteristics to memory or from an initiator (e.g. CPU), this
> +# node defines the boundary point between non-discoverable system
> +# buses which must be described by firmware, and a discoverable
> +# bus. NUMA distances and access characteristics are defined to
> +# and from that point. For system software to establish full
> +# initiator to target characteristics this information must be
> +# combined with information retrieved from the discoverable part
> +# of the path. An example would use CDAT (see UEFI.org)
> +# information read from devices and switches in conjunction with
> +# link characteristics read from PCIe Configuration space.
> +# To get the full path latency from CPU to CXL attached DRAM
> +# CXL device: Add the latency from CPU to Generic Port (from
> +# HMAT indexed via the the node ID in this SRAT structure) to
> +# that for CXL bus links, the latency across intermediate switches
> +# and from the EP port to the actual memory. Bandwidth is more
> +# complex as there may be interleaving across multiple devices
> +# and shared links in the path.
> +#
> +# Since: 9.1
This is outdated, we're in the 9.2 dev cycle currently.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
