From: Markus Armbruster <armbru@redhat.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <mst@redhat.com>, <qemu-devel@nongnu.org>, <ankita@nvidia.com>,
<marcel.apfelbaum@gmail.com>, <philmd@linaro.org>,
Dave Jiang <dave.jiang@intel.com>,
Huang Ying <ying.huang@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>, <eduardo@habkost.net>,
<imammedo@redhat.com>, <linux-cxl@vger.kernel.org>,
<linuxarm@huawei.com>, Michael Roth <michael.roth@amd.com>,
Ani Sinha <anisinha@redhat.com>
Subject: Re: [PATCH v2 3/6] hw/acpi: Generic Port Affinity Structure support
Date: Tue, 04 Jun 2024 15:59:10 +0200 [thread overview]
Message-ID: <87zfs06c7l.fsf@pond.sub.org> (raw)
In-Reply-To: <20240524100507.32106-4-Jonathan.Cameron@huawei.com> (Jonathan Cameron's message of "Fri, 24 May 2024 11:05:04 +0100")
Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
> 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 descoverable
I figure your mean "discoverable", and ...
> mechanism such as UEFI CDAT read from CXL devices and switches
> is used to discover the remainder fo the path and the OS can build
... " of the path, and the OS".
> up full latency and bandwidth numbers as need for work and data
> placement decisions.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> v2: Updates to QMP documentation to provide a lot more information
> on the parameters.
> ---
> qapi/qom.json | 35 ++++++
> include/hw/acpi/acpi_generic_initiator.h | 18 ++-
> include/hw/pci/pci_bridge.h | 1 +
> hw/acpi/acpi_generic_initiator.c | 141 +++++++++++++++++------
> hw/pci-bridge/pci_expander_bridge.c | 1 -
> 5 files changed, 158 insertions(+), 38 deletions(-)
>
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 38dde6d785..9d1d86bdad 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -826,6 +826,39 @@
> 'data': { 'pci-dev': 'str',
> 'node': 'uint32' } }
>
> +
Extra blank line.
> +##
> +# @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
I'd put the period behind the parenthesis: "bridges). See ACPI"
> +# 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.
Lines are slightly wide in places.
Together:
# @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.
> +#
> +# Since: 9.1
> +##
> +{ 'struct': 'AcpiGenericPortProperties',
> + 'data': { 'pci-bus': 'str',
> + 'node': 'uint32' } }
> +
> ##
> # @RngProperties:
> #
> @@ -953,6 +986,7 @@
> { 'enum': 'ObjectType',
> 'data': [
> 'acpi-generic-initiator',
> + 'acpi-generic-port',
> 'authz-list',
> 'authz-listfile',
> 'authz-pam',
> @@ -1025,6 +1059,7 @@
> 'discriminator': 'qom-type',
> 'data': {
> 'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
> + 'acpi-generic-port': 'AcpiGenericPortProperties',
> 'authz-list': 'AuthZListProperties',
> 'authz-listfile': 'AuthZListFileProperties',
> 'authz-pam': 'AuthZPAMProperties',
Preferably with these touch-ups
Acked-by: Markus Armbruster <armbru@redhat.com>
[...]
next prev parent reply other threads:[~2024-06-04 13:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 10:05 [PATCH v2 qemu 0/6] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
2024-05-24 10:05 ` [PATCH v2 1/6] hw/acpi/GI: Fix trivial parameter alignment issue Jonathan Cameron via
2024-05-24 10:05 ` [PATCH v2 2/6] hw/acpi: Insert an acpi-generic-node base under acpi-generic-initiator Jonathan Cameron via
2024-05-24 10:05 ` [PATCH v2 3/6] hw/acpi: Generic Port Affinity Structure support Jonathan Cameron via
2024-06-04 13:59 ` Markus Armbruster [this message]
2024-06-05 16:21 ` Jonathan Cameron via
2024-06-05 17:51 ` Richard Henderson
2024-05-24 10:05 ` [PATCH v2 4/6] bios-tables-test: Allow for new acpihmat-generic-x test data Jonathan Cameron via
2024-05-24 10:05 ` [PATCH v2 5/6] bios-tables-test: Add complex SRAT / HMAT test for GI GP Jonathan Cameron via
2024-05-24 10:05 ` [PATCH v2 6/6] bios-tables-test: Add data for complex numa test (GI, GP etc) Jonathan Cameron via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zfs06c7l.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=anisinha@redhat.com \
--cc=ankita@nvidia.com \
--cc=dave.jiang@intel.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).