* [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test.
@ 2024-04-03 10:29 Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 1/6] hw/acpi/GI: Fix trivial parameter alignment issue Jonathan Cameron via
` (6 more replies)
0 siblings, 7 replies; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-03 10:29 UTC (permalink / raw)
To: ankita, marcel.apfelbaum, philmd, mst, qemu-devel
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo, imammedo,
linux-cxl, linuxarm, Markus Armbruster, Michael Roth, Ani Sinha
ACPI 6.5 introduced Generic Port Affinity Structures to close a system
description gap that was a problem for CXL memory systems.
It defines an new SRAT Affinity structure (and hence allows creation of an
ACPI Proximity Node which can only be defined via an SRAT structure)
for the boundary between a discoverable fabric and a non discoverable
system interconnects etc.
The HMAT data on latency and bandwidth is combined with discoverable
information from the CXL bus (link speeds, lane counts) and CXL devices
(switch port to port characteristics and USP to memory, via CDAT tables
read from the device). QEMU has supported the rest of the elements
of this chain for a while but now the kernel has caught up and we need
the missing element of Generic Ports (this code has been used extensively
in testing and debugging that kernel support, some resulting fixes
currently under review).
Generic Port Affinity Structures are very similar to the recently
added Generic Initiator Affinity Structures (GI) so this series
factors out and reuses much of that infrastructure for reuse
There are subtle differences (beyond the obvious structure ID change).
- The ACPI spec example (and linux kernel support) has a Generic
Port not as associated with the CXL root port, but rather with
the CXL Host bridge. As a result, an ACPI handle is used (rather
than the PCI SBDF option for GIs). In QEMU the easiest way
to get to this is to target the root bridge PCI Bus, and
conveniently the root bridge bus number is used for the UID allowing
us to construct an appropriate entry.
A key addition of this series is a complex NUMA topology example that
stretches the QEMU emulation code for GI, GP and nodes with just
CPUS, just memory, just hot pluggable memory, mixture of memory and CPUs.
A similar test showed up a few NUMA related bugs with fixes applied for
9.0 (note that one of these needs linux booted to identify that it
rejects the HMAT table and this test is a regression test for the
table generation only).
https://lore.kernel.org/qemu-devel/2eb6672cfdaea7dacd8e9bb0523887f13b9f85ce.1710282274.git.mst@redhat.com/
https://lore.kernel.org/qemu-devel/74e2845c5f95b0c139c79233ddb65bb17f2dd679.1710282274.git.mst@redhat.com/
Jonathan Cameron (6):
hw/acpi/GI: Fix trivial parameter alignment issue.
hw/acpi: Insert an acpi-generic-node base under acpi-generic-initiator
hw/acpi: Generic Port Affinity Structure support
bios-tables-test: Allow for new acpihmat-generic-x test data.
bios-tables-test: Add complex SRAT / HMAT test for GI GP
bios-tables-test: Add data for complex numa test (GI, GP etc)
qapi/qom.json | 18 ++
include/hw/acpi/acpi_generic_initiator.h | 33 +++-
include/hw/pci/pci_bridge.h | 1 +
hw/acpi/acpi_generic_initiator.c | 199 ++++++++++++++------
hw/pci-bridge/pci_expander_bridge.c | 1 -
tests/qtest/bios-tables-test.c | 92 +++++++++
tests/data/acpi/q35/APIC.acpihmat-generic-x | Bin 0 -> 136 bytes
tests/data/acpi/q35/CEDT.acpihmat-generic-x | Bin 0 -> 68 bytes
tests/data/acpi/q35/DSDT.acpihmat-generic-x | Bin 0 -> 10400 bytes
tests/data/acpi/q35/HMAT.acpihmat-generic-x | Bin 0 -> 360 bytes
tests/data/acpi/q35/SRAT.acpihmat-generic-x | Bin 0 -> 520 bytes
11 files changed, 285 insertions(+), 59 deletions(-)
create mode 100644 tests/data/acpi/q35/APIC.acpihmat-generic-x
create mode 100644 tests/data/acpi/q35/CEDT.acpihmat-generic-x
create mode 100644 tests/data/acpi/q35/DSDT.acpihmat-generic-x
create mode 100644 tests/data/acpi/q35/HMAT.acpihmat-generic-x
create mode 100644 tests/data/acpi/q35/SRAT.acpihmat-generic-x
--
2.39.2
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 1/6] hw/acpi/GI: Fix trivial parameter alignment issue.
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
@ 2024-04-03 10:29 ` Jonathan Cameron via
2024-04-08 2:58 ` Ankit Agrawal
2024-04-03 10:29 ` [PATCH 2/6] hw/acpi: Insert an acpi-generic-node base under acpi-generic-initiator Jonathan Cameron via
` (5 subsequent siblings)
6 siblings, 1 reply; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-03 10:29 UTC (permalink / raw)
To: ankita, marcel.apfelbaum, philmd, mst, qemu-devel
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo, imammedo,
linux-cxl, linuxarm, Markus Armbruster, Michael Roth, Ani Sinha
Before making additional modification, tidy up this misleading indentation.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
hw/acpi/acpi_generic_initiator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/acpi/acpi_generic_initiator.c b/hw/acpi/acpi_generic_initiator.c
index 17b9a052f5..18a939b0e5 100644
--- a/hw/acpi/acpi_generic_initiator.c
+++ b/hw/acpi/acpi_generic_initiator.c
@@ -132,7 +132,7 @@ static int build_all_acpi_generic_initiators(Object *obj, void *opaque)
dev_handle.segment = 0;
dev_handle.bdf = PCI_BUILD_BDF(pci_bus_num(pci_get_bus(pci_dev)),
- pci_dev->devfn);
+ pci_dev->devfn);
build_srat_generic_pci_initiator_affinity(table_data,
gi->node, &dev_handle);
--
2.39.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 2/6] hw/acpi: Insert an acpi-generic-node base under acpi-generic-initiator
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 1/6] hw/acpi/GI: Fix trivial parameter alignment issue Jonathan Cameron via
@ 2024-04-03 10:29 ` Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support Jonathan Cameron via
` (4 subsequent siblings)
6 siblings, 0 replies; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-03 10:29 UTC (permalink / raw)
To: ankita, marcel.apfelbaum, philmd, mst, qemu-devel
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo, imammedo,
linux-cxl, linuxarm, Markus Armbruster, Michael Roth, Ani Sinha
This will simplify reuse when adding acpi-generic-port.
Note that some error_printf() messages will now print acpi-generic-node
whereas others will move to type specific cases in next patch so
are left alone for now.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
include/hw/acpi/acpi_generic_initiator.h | 15 ++++-
hw/acpi/acpi_generic_initiator.c | 78 +++++++++++++++---------
2 files changed, 62 insertions(+), 31 deletions(-)
diff --git a/include/hw/acpi/acpi_generic_initiator.h b/include/hw/acpi/acpi_generic_initiator.h
index a304bad73e..26e2bd92d4 100644
--- a/include/hw/acpi/acpi_generic_initiator.h
+++ b/include/hw/acpi/acpi_generic_initiator.h
@@ -8,15 +8,26 @@
#include "qom/object_interfaces.h"
-#define TYPE_ACPI_GENERIC_INITIATOR "acpi-generic-initiator"
+/*
+ * Abstract type to be used as base for
+ * - acpi-generic-initator
+ * - acpi-generic-port
+ */
+#define TYPE_ACPI_GENERIC_NODE "acpi-generic-node"
-typedef struct AcpiGenericInitiator {
+typedef struct AcpiGenericNode {
/* private */
Object parent;
/* public */
char *pci_dev;
uint16_t node;
+} AcpiGenericNode;
+
+#define TYPE_ACPI_GENERIC_INITIATOR "acpi-generic-initiator"
+
+typedef struct AcpiGenericInitiator {
+ AcpiGenericNode parent;
} AcpiGenericInitiator;
/*
diff --git a/hw/acpi/acpi_generic_initiator.c b/hw/acpi/acpi_generic_initiator.c
index 18a939b0e5..c054e0e27d 100644
--- a/hw/acpi/acpi_generic_initiator.c
+++ b/hw/acpi/acpi_generic_initiator.c
@@ -10,45 +10,61 @@
#include "hw/pci/pci_device.h"
#include "qemu/error-report.h"
-typedef struct AcpiGenericInitiatorClass {
+typedef struct AcpiGenericNodeClass {
ObjectClass parent_class;
+} AcpiGenericNodeClass;
+
+typedef struct AcpiGenericInitiatorClass {
+ AcpiGenericNodeClass parent_class;
} AcpiGenericInitiatorClass;
+OBJECT_DEFINE_ABSTRACT_TYPE(AcpiGenericNode, acpi_generic_node,
+ ACPI_GENERIC_NODE, OBJECT)
+
+OBJECT_DECLARE_SIMPLE_TYPE(AcpiGenericNode, ACPI_GENERIC_NODE)
+
OBJECT_DEFINE_TYPE_WITH_INTERFACES(AcpiGenericInitiator, acpi_generic_initiator,
- ACPI_GENERIC_INITIATOR, OBJECT,
+ ACPI_GENERIC_INITIATOR, ACPI_GENERIC_NODE,
{ TYPE_USER_CREATABLE },
{ NULL })
OBJECT_DECLARE_SIMPLE_TYPE(AcpiGenericInitiator, ACPI_GENERIC_INITIATOR)
+static void acpi_generic_node_init(Object *obj)
+{
+ AcpiGenericNode *gn = ACPI_GENERIC_NODE(obj);
+
+ gn->node = MAX_NODES;
+ gn->pci_dev = NULL;
+}
+
static void acpi_generic_initiator_init(Object *obj)
{
- AcpiGenericInitiator *gi = ACPI_GENERIC_INITIATOR(obj);
+}
+
+static void acpi_generic_node_finalize(Object *obj)
+{
+ AcpiGenericNode *gn = ACPI_GENERIC_NODE(obj);
- gi->node = MAX_NODES;
- gi->pci_dev = NULL;
+ g_free(gn->pci_dev);
}
static void acpi_generic_initiator_finalize(Object *obj)
{
- AcpiGenericInitiator *gi = ACPI_GENERIC_INITIATOR(obj);
-
- g_free(gi->pci_dev);
}
-static void acpi_generic_initiator_set_pci_device(Object *obj, const char *val,
- Error **errp)
+static void acpi_generic_node_set_pci_device(Object *obj, const char *val,
+ Error **errp)
{
- AcpiGenericInitiator *gi = ACPI_GENERIC_INITIATOR(obj);
+ AcpiGenericNode *gn = ACPI_GENERIC_NODE(obj);
- gi->pci_dev = g_strdup(val);
+ gn->pci_dev = g_strdup(val);
}
-
-static void acpi_generic_initiator_set_node(Object *obj, Visitor *v,
- const char *name, void *opaque,
- Error **errp)
+static void acpi_generic_node_set_node(Object *obj, Visitor *v,
+ const char *name, void *opaque,
+ Error **errp)
{
- AcpiGenericInitiator *gi = ACPI_GENERIC_INITIATOR(obj);
+ AcpiGenericNode *gn = ACPI_GENERIC_NODE(obj);
MachineState *ms = MACHINE(qdev_get_machine());
uint32_t value;
@@ -58,20 +74,24 @@ static void acpi_generic_initiator_set_node(Object *obj, Visitor *v,
if (value >= MAX_NODES) {
error_printf("%s: Invalid NUMA node specified\n",
- TYPE_ACPI_GENERIC_INITIATOR);
+ TYPE_ACPI_GENERIC_NODE);
exit(1);
}
- gi->node = value;
- ms->numa_state->nodes[gi->node].has_gi = true;
+ gn->node = value;
+ ms->numa_state->nodes[gn->node].has_gi = true;
}
-static void acpi_generic_initiator_class_init(ObjectClass *oc, void *data)
+static void acpi_generic_node_class_init(ObjectClass *oc, void *data)
{
object_class_property_add_str(oc, "pci-dev", NULL,
- acpi_generic_initiator_set_pci_device);
+ acpi_generic_node_set_pci_device);
object_class_property_add(oc, "node", "int", NULL,
- acpi_generic_initiator_set_node, NULL, NULL);
+ acpi_generic_node_set_node, NULL, NULL);
+}
+
+static void acpi_generic_initiator_class_init(ObjectClass *oc, void *data)
+{
}
/*
@@ -104,9 +124,9 @@ build_srat_generic_pci_initiator_affinity(GArray *table_data, int node,
static int build_all_acpi_generic_initiators(Object *obj, void *opaque)
{
MachineState *ms = MACHINE(qdev_get_machine());
- AcpiGenericInitiator *gi;
GArray *table_data = opaque;
PCIDeviceHandle dev_handle;
+ AcpiGenericNode *gn;
PCIDevice *pci_dev;
Object *o;
@@ -114,14 +134,14 @@ static int build_all_acpi_generic_initiators(Object *obj, void *opaque)
return 0;
}
- gi = ACPI_GENERIC_INITIATOR(obj);
- if (gi->node >= ms->numa_state->num_nodes) {
+ gn = ACPI_GENERIC_NODE(obj);
+ if (gn->node >= ms->numa_state->num_nodes) {
error_printf("%s: Specified node %d is invalid.\n",
- TYPE_ACPI_GENERIC_INITIATOR, gi->node);
+ TYPE_ACPI_GENERIC_INITIATOR, gn->node);
exit(1);
}
- o = object_resolve_path_type(gi->pci_dev, TYPE_PCI_DEVICE, NULL);
+ o = object_resolve_path_type(gn->pci_dev, TYPE_PCI_DEVICE, NULL);
if (!o) {
error_printf("%s: Specified device must be a PCI device.\n",
TYPE_ACPI_GENERIC_INITIATOR);
@@ -135,7 +155,7 @@ static int build_all_acpi_generic_initiators(Object *obj, void *opaque)
pci_dev->devfn);
build_srat_generic_pci_initiator_affinity(table_data,
- gi->node, &dev_handle);
+ gn->node, &dev_handle);
return 0;
}
--
2.39.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 1/6] hw/acpi/GI: Fix trivial parameter alignment issue Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 2/6] hw/acpi: Insert an acpi-generic-node base under acpi-generic-initiator Jonathan Cameron via
@ 2024-04-03 10:29 ` Jonathan Cameron via
2024-04-23 10:56 ` Markus Armbruster
2024-04-03 10:29 ` [PATCH 4/6] bios-tables-test: Allow for new acpihmat-generic-x test data Jonathan Cameron via
` (3 subsequent siblings)
6 siblings, 1 reply; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-03 10:29 UTC (permalink / raw)
To: ankita, marcel.apfelbaum, philmd, mst, qemu-devel
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo, imammedo,
linux-cxl, linuxarm, Markus Armbruster, Michael Roth, Ani Sinha
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
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
up full latency and bandwidth numbers as need for work and data
placement decisions.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
qapi/qom.json | 18 +++
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, 141 insertions(+), 38 deletions(-)
diff --git a/qapi/qom.json b/qapi/qom.json
index 85e6b4f84a..5480d9ca24 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -826,6 +826,22 @@
'data': { 'pci-dev': 'str',
'node': 'uint32' } }
+
+##
+# @AcpiGenericPortProperties:
+#
+# Properties for acpi-generic-port objects.
+#
+# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry
+#
+# @node: numa node associated with the PCI device
+#
+# Since: 9.1
+##
+{ 'struct': 'AcpiGenericPortProperties',
+ 'data': { 'pci-bus': 'str',
+ 'node': 'uint32' } }
+
##
# @RngProperties:
#
@@ -944,6 +960,7 @@
{ 'enum': 'ObjectType',
'data': [
'acpi-generic-initiator',
+ 'acpi-generic-port',
'authz-list',
'authz-listfile',
'authz-pam',
@@ -1016,6 +1033,7 @@
'discriminator': 'qom-type',
'data': {
'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
+ 'acpi-generic-port': 'AcpiGenericPortProperties',
'authz-list': 'AuthZListProperties',
'authz-listfile': 'AuthZListFileProperties',
'authz-pam': 'AuthZPAMProperties',
diff --git a/include/hw/acpi/acpi_generic_initiator.h b/include/hw/acpi/acpi_generic_initiator.h
index 26e2bd92d4..49ac448034 100644
--- a/include/hw/acpi/acpi_generic_initiator.h
+++ b/include/hw/acpi/acpi_generic_initiator.h
@@ -30,6 +30,12 @@ typedef struct AcpiGenericInitiator {
AcpiGenericNode parent;
} AcpiGenericInitiator;
+#define TYPE_ACPI_GENERIC_PORT "acpi-generic-port"
+
+typedef struct AcpiGenericPort {
+ AcpiGenericInitiator parent;
+} AcpiGenericPort;
+
/*
* ACPI 6.3:
* Table 5-81 Flags – Generic Initiator Affinity Structure
@@ -49,8 +55,16 @@ typedef enum {
* Table 5-80 Device Handle - PCI
*/
typedef struct PCIDeviceHandle {
- uint16_t segment;
- uint16_t bdf;
+ union {
+ struct {
+ uint16_t segment;
+ uint16_t bdf;
+ };
+ struct {
+ uint64_t hid;
+ uint32_t uid;
+ };
+ };
} PCIDeviceHandle;
void build_srat_generic_pci_initiator(GArray *table_data);
diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index 5cd452115a..5456e24883 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -102,6 +102,7 @@ typedef struct PXBPCIEDev {
PXBDev parent_obj;
} PXBPCIEDev;
+#define TYPE_PXB_CXL_BUS "pxb-cxl-bus"
#define TYPE_PXB_DEV "pxb"
OBJECT_DECLARE_SIMPLE_TYPE(PXBDev, PXB_DEV)
diff --git a/hw/acpi/acpi_generic_initiator.c b/hw/acpi/acpi_generic_initiator.c
index c054e0e27d..85191e90ab 100644
--- a/hw/acpi/acpi_generic_initiator.c
+++ b/hw/acpi/acpi_generic_initiator.c
@@ -7,6 +7,7 @@
#include "hw/acpi/acpi_generic_initiator.h"
#include "hw/acpi/aml-build.h"
#include "hw/boards.h"
+#include "hw/pci/pci_bridge.h"
#include "hw/pci/pci_device.h"
#include "qemu/error-report.h"
@@ -18,6 +19,10 @@ typedef struct AcpiGenericInitiatorClass {
AcpiGenericNodeClass parent_class;
} AcpiGenericInitiatorClass;
+typedef struct AcpiGenericPortClass {
+ AcpiGenericInitiatorClass parent;
+} AcpiGenericPortClass;
+
OBJECT_DEFINE_ABSTRACT_TYPE(AcpiGenericNode, acpi_generic_node,
ACPI_GENERIC_NODE, OBJECT)
@@ -30,6 +35,13 @@ OBJECT_DEFINE_TYPE_WITH_INTERFACES(AcpiGenericInitiator, acpi_generic_initiator,
OBJECT_DECLARE_SIMPLE_TYPE(AcpiGenericInitiator, ACPI_GENERIC_INITIATOR)
+OBJECT_DEFINE_TYPE_WITH_INTERFACES(AcpiGenericPort, acpi_generic_port,
+ ACPI_GENERIC_PORT, ACPI_GENERIC_NODE,
+ { TYPE_USER_CREATABLE },
+ { NULL })
+
+OBJECT_DECLARE_SIMPLE_TYPE(AcpiGenericPort, ACPI_GENERIC_PORT)
+
static void acpi_generic_node_init(Object *obj)
{
AcpiGenericNode *gn = ACPI_GENERIC_NODE(obj);
@@ -53,6 +65,14 @@ static void acpi_generic_initiator_finalize(Object *obj)
{
}
+static void acpi_generic_port_init(Object *obj)
+{
+}
+
+static void acpi_generic_port_finalize(Object *obj)
+{
+}
+
static void acpi_generic_node_set_pci_device(Object *obj, const char *val,
Error **errp)
{
@@ -79,42 +99,61 @@ static void acpi_generic_node_set_node(Object *obj, Visitor *v,
}
gn->node = value;
- ms->numa_state->nodes[gn->node].has_gi = true;
+ if (object_dynamic_cast(obj, TYPE_ACPI_GENERIC_INITIATOR)) {
+ ms->numa_state->nodes[gn->node].has_gi = true;
+ }
}
static void acpi_generic_node_class_init(ObjectClass *oc, void *data)
{
- object_class_property_add_str(oc, "pci-dev", NULL,
- acpi_generic_node_set_pci_device);
object_class_property_add(oc, "node", "int", NULL,
acpi_generic_node_set_node, NULL, NULL);
}
static void acpi_generic_initiator_class_init(ObjectClass *oc, void *data)
{
+ object_class_property_add_str(oc, "pci-dev", NULL,
+ acpi_generic_node_set_pci_device);
+}
+
+static void acpi_generic_port_class_init(ObjectClass *oc, void *data)
+{
+ /*
+ * Despite the ID representing a root bridge bus, same storage
+ * can be used.
+ */
+ object_class_property_add_str(oc, "pci-bus", NULL,
+ acpi_generic_node_set_pci_device);
}
/*
* ACPI 6.3:
* Table 5-78 Generic Initiator Affinity Structure
+ * ACPI 6.5:
+ * Table 5-67 Generic Port Affinity Structure
*/
static void
-build_srat_generic_pci_initiator_affinity(GArray *table_data, int node,
- PCIDeviceHandle *handle)
+build_srat_generic_node_affinity(GArray *table_data, int node,
+ PCIDeviceHandle *handle, bool gp, bool pci)
{
- uint8_t index;
-
- build_append_int_noprefix(table_data, 5, 1); /* Type */
+ build_append_int_noprefix(table_data, gp ? 6 : 5, 1); /* Type */
build_append_int_noprefix(table_data, 32, 1); /* Length */
build_append_int_noprefix(table_data, 0, 1); /* Reserved */
- build_append_int_noprefix(table_data, 1, 1); /* Device Handle Type: PCI */
+ /* Device Handle Type: PCI / ACPI */
+ build_append_int_noprefix(table_data, pci ? 1 : 0, 1);
build_append_int_noprefix(table_data, node, 4); /* Proximity Domain */
/* Device Handle - PCI */
- build_append_int_noprefix(table_data, handle->segment, 2);
- build_append_int_noprefix(table_data, handle->bdf, 2);
- for (index = 0; index < 12; index++) {
- build_append_int_noprefix(table_data, 0, 1);
+ if (pci) {
+ /* Device Handle - PCI */
+ build_append_int_noprefix(table_data, handle->segment, 2);
+ build_append_int_noprefix(table_data, handle->bdf, 2);
+ build_append_int_noprefix(table_data, 0, 12);
+ } else {
+ /* Device Handle - ACPI */
+ build_append_int_noprefix(table_data, handle->hid, 8);
+ build_append_int_noprefix(table_data, handle->uid, 4);
+ build_append_int_noprefix(table_data, 0, 4);
}
build_append_int_noprefix(table_data, GEN_AFFINITY_ENABLED, 4); /* Flags */
@@ -127,37 +166,69 @@ static int build_all_acpi_generic_initiators(Object *obj, void *opaque)
GArray *table_data = opaque;
PCIDeviceHandle dev_handle;
AcpiGenericNode *gn;
- PCIDevice *pci_dev;
Object *o;
- if (!object_dynamic_cast(obj, TYPE_ACPI_GENERIC_INITIATOR)) {
+ if (!object_dynamic_cast(obj, TYPE_ACPI_GENERIC_NODE)) {
return 0;
}
gn = ACPI_GENERIC_NODE(obj);
- if (gn->node >= ms->numa_state->num_nodes) {
- error_printf("%s: Specified node %d is invalid.\n",
- TYPE_ACPI_GENERIC_INITIATOR, gn->node);
- exit(1);
- }
- o = object_resolve_path_type(gn->pci_dev, TYPE_PCI_DEVICE, NULL);
- if (!o) {
- error_printf("%s: Specified device must be a PCI device.\n",
- TYPE_ACPI_GENERIC_INITIATOR);
- exit(1);
- }
-
- pci_dev = PCI_DEVICE(o);
-
- dev_handle.segment = 0;
- dev_handle.bdf = PCI_BUILD_BDF(pci_bus_num(pci_get_bus(pci_dev)),
- pci_dev->devfn);
+ if (object_dynamic_cast(OBJECT(gn), TYPE_ACPI_GENERIC_INITIATOR)) {
+ PCIDevice *pci_dev;
+
+ if (gn->node >= ms->numa_state->num_nodes) {
+ error_printf("%s: Specified node %d is invalid.\n",
+ TYPE_ACPI_GENERIC_INITIATOR, gn->node);
+ exit(1);
+ }
+
+ o = object_resolve_path_type(gn->pci_dev, TYPE_PCI_DEVICE, NULL);
+ if (!o) {
+ error_printf("%s: Specified device must be a PCI device.\n",
+ TYPE_ACPI_GENERIC_INITIATOR);
+ exit(1);
+ }
+ pci_dev = PCI_DEVICE(o);
+
+ dev_handle.segment = 0;
+ dev_handle.bdf = PCI_BUILD_BDF(pci_bus_num(pci_get_bus(pci_dev)),
+ pci_dev->devfn);
+ build_srat_generic_node_affinity(table_data,
+ gn->node, &dev_handle, false, true);
- build_srat_generic_pci_initiator_affinity(table_data,
- gn->node, &dev_handle);
+ return 0;
+ } else { /* TYPE_ACPI_GENERIC_PORT */
+ PCIBus *bus;
+ const char *hid = "ACPI0016";
+
+ if (gn->node >= ms->numa_state->num_nodes) {
+ error_printf("%s: Specified node %d is invalid.\n",
+ TYPE_ACPI_GENERIC_PORT, gn->node);
+ exit(1);
+ }
+
+ o = object_resolve_path_type(gn->pci_dev, TYPE_PCI_BUS, NULL);
+ if (!o) {
+ error_printf("%s: Specified device must be a PCI Host Bridge.\n",
+ TYPE_ACPI_GENERIC_PORT);
+ exit(1);
+ }
+ bus = PCI_BUS(o);
+ /* Need to know if this is a PXB Bus so below an expander bridge */
+ if (!object_dynamic_cast(OBJECT(bus), TYPE_PXB_CXL_BUS)) {
+ error_printf("%s: Specified device is not a bus below a host bridge.\n",
+ TYPE_ACPI_GENERIC_PORT);
+ exit(1);
+ }
+ /* Copy without trailing NULL */
+ memcpy(&dev_handle.hid, hid, sizeof(dev_handle.hid));
+ dev_handle.uid = pci_bus_num(bus);
+ build_srat_generic_node_affinity(table_data,
+ gn->node, &dev_handle, true, false);
- return 0;
+ return 0;
+ }
}
void build_srat_generic_pci_initiator(GArray *table_data)
diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c
index 0411ad31ea..f5431443b9 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -38,7 +38,6 @@ DECLARE_INSTANCE_CHECKER(PXBBus, PXB_BUS,
DECLARE_INSTANCE_CHECKER(PXBBus, PXB_PCIE_BUS,
TYPE_PXB_PCIE_BUS)
-#define TYPE_PXB_CXL_BUS "pxb-cxl-bus"
DECLARE_INSTANCE_CHECKER(PXBBus, PXB_CXL_BUS,
TYPE_PXB_CXL_BUS)
--
2.39.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 4/6] bios-tables-test: Allow for new acpihmat-generic-x test data.
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
` (2 preceding siblings ...)
2024-04-03 10:29 ` [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support Jonathan Cameron via
@ 2024-04-03 10:29 ` Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 5/6] bios-tables-test: Add complex SRAT / HMAT test for GI GP Jonathan Cameron via
` (2 subsequent siblings)
6 siblings, 0 replies; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-03 10:29 UTC (permalink / raw)
To: ankita, marcel.apfelbaum, philmd, mst, qemu-devel
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo, imammedo,
linux-cxl, linuxarm, Markus Armbruster, Michael Roth, Ani Sinha
The test to be added exercises many corners of the SRAT and HMAT
table generation.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
tests/qtest/bios-tables-test-allowed-diff.h | 5 +++++
tests/data/acpi/q35/APIC.acpihmat-generic-x | 0
tests/data/acpi/q35/CEDT.acpihmat-generic-x | 0
tests/data/acpi/q35/DSDT.acpihmat-generic-x | 0
tests/data/acpi/q35/HMAT.acpihmat-generic-x | 0
tests/data/acpi/q35/SRAT.acpihmat-generic-x | 0
6 files changed, 5 insertions(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..a5aa801c99 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,6 @@
/* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/q35/APIC.acpihmat-generic-x",
+"tests/data/acpi/q35/CEDT.acpihmat-generic-x",
+"tests/data/acpi/q35/DSDT.acpihmat-generic-x",
+"tests/data/acpi/q35/HMAT.acpihmat-generic-x",
+"tests/data/acpi/q35/SRAT.acpihmat-generic-x",
diff --git a/tests/data/acpi/q35/APIC.acpihmat-generic-x b/tests/data/acpi/q35/APIC.acpihmat-generic-x
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/data/acpi/q35/CEDT.acpihmat-generic-x b/tests/data/acpi/q35/CEDT.acpihmat-generic-x
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/data/acpi/q35/DSDT.acpihmat-generic-x b/tests/data/acpi/q35/DSDT.acpihmat-generic-x
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/data/acpi/q35/HMAT.acpihmat-generic-x b/tests/data/acpi/q35/HMAT.acpihmat-generic-x
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/data/acpi/q35/SRAT.acpihmat-generic-x b/tests/data/acpi/q35/SRAT.acpihmat-generic-x
new file mode 100644
index 0000000000..e69de29bb2
--
2.39.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 5/6] bios-tables-test: Add complex SRAT / HMAT test for GI GP
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
` (3 preceding siblings ...)
2024-04-03 10:29 ` [PATCH 4/6] bios-tables-test: Allow for new acpihmat-generic-x test data Jonathan Cameron via
@ 2024-04-03 10:29 ` Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 6/6] bios-tables-test: Add data for complex numa test (GI, GP etc) Jonathan Cameron via
2024-04-12 7:39 ` [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Huang, Ying
6 siblings, 0 replies; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-03 10:29 UTC (permalink / raw)
To: ankita, marcel.apfelbaum, philmd, mst, qemu-devel
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo, imammedo,
linux-cxl, linuxarm, Markus Armbruster, Michael Roth, Ani Sinha
Add a test with 6 nodes to exercise most interesting corner cases
of SRAT and HMAT generation including the new Generic Initiator
and Generic Port Affinity structures. More details of the
set up in the following patch adding the table data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
tests/qtest/bios-tables-test.c | 92 ++++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index d1ff4db7a2..1651d06b7b 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -1862,6 +1862,96 @@ static void test_acpi_q35_tcg_acpi_hmat_noinitiator(void)
free_test_data(&data);
}
+/* Test intended to hit corner cases of SRAT and HMAT */
+static void test_acpi_q35_tcg_acpi_hmat_generic_x(void)
+{
+ test_data data = {};
+
+ data.machine = MACHINE_Q35;
+ data.variant = ".acpihmat-generic-x";
+ test_acpi_one(" -machine hmat=on,cxl=on"
+ " -smp 3,sockets=3"
+ " -m 128M,maxmem=384M,slots=2"
+ " -device virtio-rng-pci,id=gidev"
+ " -device pxb-cxl,bus_nr=64,bus=pcie.0,id=cxl.1"
+ " -object memory-backend-ram,size=64M,id=ram0"
+ " -object memory-backend-ram,size=64M,id=ram1"
+ " -numa node,nodeid=0,cpus=0,memdev=ram0"
+ " -numa node,nodeid=1"
+ " -object acpi-generic-initiator,id=gi0,pci-dev=gidev,node=1"
+ " -numa node,nodeid=2"
+ " -object acpi-generic-port,id=gp0,pci-bus=cxl.1,node=2"
+ " -numa node,nodeid=3,cpus=1"
+ " -numa node,nodeid=4,memdev=ram1"
+ " -numa node,nodeid=5,cpus=2"
+ " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
+ "data-type=access-latency,latency=10"
+ " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=800M"
+ " -numa hmat-lb,initiator=0,target=2,hierarchy=memory,"
+ "data-type=access-latency,latency=100"
+ " -numa hmat-lb,initiator=0,target=2,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=200M"
+ " -numa hmat-lb,initiator=0,target=4,hierarchy=memory,"
+ "data-type=access-latency,latency=100"
+ " -numa hmat-lb,initiator=0,target=4,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=200M"
+ " -numa hmat-lb,initiator=0,target=5,hierarchy=memory,"
+ "data-type=access-latency,latency=200"
+ " -numa hmat-lb,initiator=0,target=5,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=400M"
+ " -numa hmat-lb,initiator=1,target=0,hierarchy=memory,"
+ "data-type=access-latency,latency=500"
+ " -numa hmat-lb,initiator=1,target=0,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=100M"
+ " -numa hmat-lb,initiator=1,target=2,hierarchy=memory,"
+ "data-type=access-latency,latency=50"
+ " -numa hmat-lb,initiator=1,target=2,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=400M"
+ " -numa hmat-lb,initiator=1,target=4,hierarchy=memory,"
+ "data-type=access-latency,latency=50"
+ " -numa hmat-lb,initiator=1,target=4,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=800M"
+ " -numa hmat-lb,initiator=1,target=5,hierarchy=memory,"
+ "data-type=access-latency,latency=500"
+ " -numa hmat-lb,initiator=1,target=5,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=100M"
+ " -numa hmat-lb,initiator=3,target=0,hierarchy=memory,"
+ "data-type=access-latency,latency=20"
+ " -numa hmat-lb,initiator=3,target=0,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=400M"
+ " -numa hmat-lb,initiator=3,target=2,hierarchy=memory,"
+ "data-type=access-latency,latency=80"
+ " -numa hmat-lb,initiator=3,target=2,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=200M"
+ " -numa hmat-lb,initiator=3,target=4,hierarchy=memory,"
+ "data-type=access-latency,latency=80"
+ " -numa hmat-lb,initiator=3,target=4,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=200M"
+ " -numa hmat-lb,initiator=3,target=5,hierarchy=memory,"
+ "data-type=access-latency,latency=20"
+ " -numa hmat-lb,initiator=3,target=5,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=400M"
+ " -numa hmat-lb,initiator=5,target=0,hierarchy=memory,"
+ "data-type=access-latency,latency=20"
+ " -numa hmat-lb,initiator=5,target=0,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=400M"
+ " -numa hmat-lb,initiator=5,target=2,hierarchy=memory,"
+ "data-type=access-latency,latency=80"
+ " -numa hmat-lb,initiator=5,target=4,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=200M"
+ " -numa hmat-lb,initiator=5,target=4,hierarchy=memory,"
+ "data-type=access-latency,latency=80"
+ " -numa hmat-lb,initiator=5,target=2,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=200M"
+ " -numa hmat-lb,initiator=5,target=5,hierarchy=memory,"
+ "data-type=access-latency,latency=10"
+ " -numa hmat-lb,initiator=5,target=5,hierarchy=memory,"
+ "data-type=access-bandwidth,bandwidth=800M",
+ &data);
+ free_test_data(&data);
+}
+
#ifdef CONFIG_POSIX
static void test_acpi_erst(const char *machine)
{
@@ -2304,6 +2394,8 @@ int main(int argc, char *argv[])
qtest_add_func("acpi/q35/nohpet", test_acpi_q35_tcg_nohpet);
qtest_add_func("acpi/q35/acpihmat-noinitiator",
test_acpi_q35_tcg_acpi_hmat_noinitiator);
+ qtest_add_func("acpi/q35/acpihmat-genericx",
+ test_acpi_q35_tcg_acpi_hmat_generic_x);
/* i386 does not support memory hotplug */
if (strcmp(arch, "i386")) {
--
2.39.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 6/6] bios-tables-test: Add data for complex numa test (GI, GP etc)
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
` (4 preceding siblings ...)
2024-04-03 10:29 ` [PATCH 5/6] bios-tables-test: Add complex SRAT / HMAT test for GI GP Jonathan Cameron via
@ 2024-04-03 10:29 ` Jonathan Cameron via
2024-04-12 7:39 ` [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Huang, Ying
6 siblings, 0 replies; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-03 10:29 UTC (permalink / raw)
To: ankita, marcel.apfelbaum, philmd, mst, qemu-devel
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo, imammedo,
linux-cxl, linuxarm, Markus Armbruster, Michael Roth, Ani Sinha
Given this is a new configuration, there are affects on APIC, CEDT
and DSDT, but the key elements are in SRAT (plus related data in
HMAT). The configuration has node to exercise many different combinations.
0) CPUs + Memory
1) GI only
2) GP only
3) CPUS only
4) Memory only
5) CPUs + HP memory
GI node, GP Node, Memory only node, hotplug memory
only node, latency and bandwidth such that in Linux Access0
(any initiator) and Access1 (CPU initiators only) given different
answers. Following cropped to remove details of each entry.
[000h 0000 004h] Signature : "SRAT" [System Resource Affinity Table]
[030h 0048 001h] Subtable Type : 00 [Processor Local APIC/SAPIC Affinity]
[032h 0050 001h] Proximity Domain Low(8) : 00
[033h 0051 001h] Apic ID : 00
[040h 0064 001h] Subtable Type : 00 [Processor Local APIC/SAPIC Affinity]
[042h 0066 001h] Proximity Domain Low(8) : 03 [043h 0067 001h] Apic ID : 01
[050h 0080 001h] Subtable Type : 00 [Processor Local APIC/SAPIC Affinity]
[052h 0082 001h] Proximity Domain Low(8) : 05
[053h 0083 001h] Apic ID : 02
[060h 0096 001h] Subtable Type : 01 [Memory Affinity]
[062h 0098 004h] Proximity Domain : 00000000
[068h 0104 008h] Base Address : 0000000000000000
[070h 0112 008h] Address Length : 00000000000A0000
[088h 0136 001h] Subtable Type : 01 [Memory Affinity]
[08Ah 0138 004h] Proximity Domain : 00000000
[090h 0144 008h] Base Address : 0000000000100000
[098h 0152 008h] Address Length : 0000000003F00000
[0A8h 0168 008h] Reserved3 : 0000000000000000
[0B0h 0176 001h] Subtable Type : 01 [Memory Affinity]
[0B2h 0178 004h] Proximity Domain : 00000004
[0B8h 0184 008h] Base Address : 0000000004000000
[0C0h 0192 008h] Address Length : 0000000004000000
//Comment in hw/i386/aml-build.c on why these exist - not part of
//ACPI requirements.
[0D8h 0216 001h] Subtable Type : 01 [Memory Affinity]
[0DAh 0218 004h] Proximity Domain : 00000000
[0E0h 0224 008h] Base Address : 0000000000000000
[0E8h 0232 008h] Address Length : 0000000000000000
[100h 0256 001h] Subtable Type : 01 [Memory Affinity]
[102h 0258 004h] Proximity Domain : 00000000
[108h 0264 008h] Base Address : 0000000000000000
[110h 0272 008h] Address Length : 0000000000000000
[128h 0296 001h] Subtable Type : 01 [Memory Affinity]
[12Ah 0298 004h] Proximity Domain : 00000000
[130h 0304 008h] Base Address : 0000000000000000
[138h 0312 008h] Address Length : 0000000000000000
[150h 0336 001h] Subtable Type : 01 [Memory Affinity]
[152h 0338 004h] Proximity Domain : 00000000
[158h 0344 008h] Base Address : 0000000000000000
[160h 0352 008h] Address Length : 0000000000000000
[178h 0376 001h] Subtable Type : 01 [Memory Affinity]
[17Ah 0378 004h] Proximity Domain : 00000000
[180h 0384 008h] Base Address : 0000000000000000
[188h 0392 008h] Address Length : 0000000000000000
// End of strange empty Memory Affinity structures.
[1A0h 0416 001h] Subtable Type : 05 [Generic Initiator Affinity]
[1A3h 0419 001h] Device Handle Type : 01
[1A4h 0420 004h] Proximity Domain : 00000001
[1A8h 0424 010h] Device Handle : 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00
[1C0h 0448 001h] Subtable Type : 06 [Generic Port Affinity]
[1C3h 0451 001h] Device Handle Type : 00
[1C4h 0452 004h] Proximity Domain : 00000002
[1C8h 0456 010h] Device Handle : 41 43 50 49 30 30 31 36 40 00 00 00 00 00 00 00
[1E0h 0480 001h] Subtable Type : 01 [Memory Affinity]
[1E2h 0482 004h] Proximity Domain : 00000005
[1E8h 0488 008h] Base Address : 0000000100000000
[1F0h 0496 008h] Address Length : 0000000090000000
[1FCh 0508 004h] Flags (decoded below) : 00000003
Enabled : 1
Hot Pluggable : 1
Non-Volatile : 0
Example block from HMAT:
[0F0h 0240 002h] Structure Type : 0001 [System Locality Latency and Bandwidth Information] [0F2h 0242 002h] Reserved : 0000 [0F4h 0244 004h] Length : 00000078 [0F8h 0248 001h] Flags (decoded below) : 00 Memory Hierarchy : 0 Use Minimum Transfer Size : 0 Non-sequential Transfers : 0
[0F9h 0249 001h] Data Type : 03
[0FAh 0250 001h] Minimum Transfer Size : 00
[0FBh 0251 001h] Reserved1 : 00
[0FCh 0252 004h] Initiator Proximity Domains # : 00000004
[100h 0256 004h] Target Proximity Domains # : 00000006
[104h 0260 004h] Reserved2 : 00000000
[108h 0264 008h] Entry Base Unit : 0000000000000004
[110h 0272 004h] Initiator Proximity Domain List : 00000000
[114h 0276 004h] Initiator Proximity Domain List : 00000001
[118h 0280 004h] Initiator Proximity Domain List : 00000003
[11Ch 0284 004h] Initiator Proximity Domain List : 00000005
[120h 0288 004h] Target Proximity Domain List : 00000000
[124h 0292 004h] Target Proximity Domain List : 00000001
[128h 0296 004h] Target Proximity Domain List : 00000002
[12Ch 0300 004h] Target Proximity Domain List : 00000003
[130h 0304 004h] Target Proximity Domain List : 00000004
[134h 0308 004h] Target Proximity Domain List : 00000005
[138h 0312 002h] Entry : 00C8
[13Ah 0314 002h] Entry : 0000
[13Ch 0316 002h] Entry : 0032
[13Eh 0318 002h] Entry : 0000
[140h 0320 002h] Entry : 0032
[142h 0322 002h] Entry : 0064
[144h 0324 002h] Entry : 0019
[146h 0326 002h] Entry : 0000
[148h 0328 002h] Entry : 0064
[14Ah 0330 002h] Entry : 0000
[14Ch 0332 002h] Entry : 00C8
[14Eh 0334 002h] Entry : 0019
[150h 0336 002h] Entry : 0064
[152h 0338 002h] Entry : 0000
[154h 0340 002h] Entry : 0032
[156h 0342 002h] Entry : 0000
[158h 0344 002h] Entry : 0032
[15Ah 0346 002h] Entry : 0064
[15Ch 0348 002h] Entry : 0064
[15Eh 0350 002h] Entry : 0000
[160h 0352 002h] Entry : 0032
[162h 0354 002h] Entry : 0000
[164h 0356 002h] Entry : 0032
[166h 0358 002h] Entry : 00C8
Note the zeros represent entries where the target node has no
memory. These could be surpressed but it isn't 'wrong' to provide
them and it is (probably) permissible under ACPI to hotplug memory
into these nodes later.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
tests/qtest/bios-tables-test-allowed-diff.h | 5 -----
tests/data/acpi/q35/APIC.acpihmat-generic-x | Bin 0 -> 136 bytes
tests/data/acpi/q35/CEDT.acpihmat-generic-x | Bin 0 -> 68 bytes
tests/data/acpi/q35/DSDT.acpihmat-generic-x | Bin 0 -> 10400 bytes
tests/data/acpi/q35/HMAT.acpihmat-generic-x | Bin 0 -> 360 bytes
tests/data/acpi/q35/SRAT.acpihmat-generic-x | Bin 0 -> 520 bytes
6 files changed, 5 deletions(-)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h
index a5aa801c99..dfb8523c8b 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1,6 +1 @@
/* List of comma-separated changed AML files to ignore */
-"tests/data/acpi/q35/APIC.acpihmat-generic-x",
-"tests/data/acpi/q35/CEDT.acpihmat-generic-x",
-"tests/data/acpi/q35/DSDT.acpihmat-generic-x",
-"tests/data/acpi/q35/HMAT.acpihmat-generic-x",
-"tests/data/acpi/q35/SRAT.acpihmat-generic-x",
diff --git a/tests/data/acpi/q35/APIC.acpihmat-generic-x b/tests/data/acpi/q35/APIC.acpihmat-generic-x
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..317ddb3fbed94e4f49a87976fdc7f23b1a6c3fdc 100644
GIT binary patch
literal 136
zcmZ<^@O18AU|?WQaPoKd2v%^42yj*a0!E-1hz+6{7#{os(;N&85Soz@LNhUeXht58
ongjnpBoh}9gBTzdD=U!Z1+h3eVJt470*DwlH<-o3_8({j09efo0RR91
literal 0
HcmV?d00001
diff --git a/tests/data/acpi/q35/CEDT.acpihmat-generic-x b/tests/data/acpi/q35/CEDT.acpihmat-generic-x
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..31c9011663639b4a0f4816f3b2b06398f94682f7 100644
GIT binary patch
literal 68
zcmZ>EbqR4{U|?Xhb@F%i2v%^42yj*a0!E-1hz+6{7!(*BfFy(s;xkNuupuM>Q<et-
literal 0
HcmV?d00001
diff --git a/tests/data/acpi/q35/DSDT.acpihmat-generic-x b/tests/data/acpi/q35/DSDT.acpihmat-generic-x
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..a04451374d1b95764d34fbda1ec791a89ffdcc46 100644
GIT binary patch
literal 10400
zcmcIqUu+x6d7t4QX*FC)6t$LpKA%na?viVg-cj<O3)-e<a!HZ2xe`svcP`cdmy(=H
zz7)6hos07s24o$OIDSZS$2e%;=mYcTt$ir^R>VN_kh~cPf*eqwKp*;&#|A}QposeW
zW_IZrk^<s~NWgNw+3)v#^P8QW-|Xy`+vSb^YmD)=(z;t~=Sx?cZXSP}F-B$j&DK-b
zn7>ypRXaSBNOAvOMwW3XS<Y9=r7Knb_dCH4g5ZO11-u)w&CjwAH@o4-_k&GFPPaBg
zA*hhOwAg8vI{torzUkHrR;N}k+r=lsvO2CRC9TetdYL(m>CSrFO+9#*x#f43`)ldm
z&cdR|`rf~v`Q51#7k=>02gS!<`}Nl!yem?0Si!G_-!mZ{f;)jY8T7NC_ICMQg3EKu
z{l!mv^0cbU(wQ)znn$*(qEO3&cb!Y=O1bUL_Rsfjuy7&CS<pZJscOKJH-GV8?Q<V_
zpB(*-_rkxq-XQ2tKin0GK@f_2_XEaIaiVuaOozF2g3Yo3z3>gjx?xwH^!LA7ZWUe0
ze73pPEVzYb2KKG?!YOg$TSpnQsmtl_pAHTVeyWNrdz)n&&g;~9)N%e^(`|3?%wt<v
z{=F<2F6yu3aVY2gy>{gyF4fO%k;1hi!z~pm7jdGr=Cyd{iGq>gme#I#`DVR*HShCM
z!@b0uSDS9-V#0r!tb>DahdjdDe3wxS|BF;TV9u9|z)bR@SRoyP$Tx6GGfml_<*DcD
zQ1lulksXKwXPdYTcYB+xw`rqq4%po;@80d+=3@F;2lrn!dVeH9xT!9K)vUX#%&|N8
z<>3xl+5NXU^>5bwjU1cJ)<!dT>HWQ2CY3?1#@eL{Q)Q0wD$ChaFA^}Sv5|yPW4YNB
z+K0=i{344`aGX=;Bo3~zNl3((z6pthZ)6cNc1<vegsVitBqUlReUlOyw;;&~8M`JG
z60Q;nlaO(iltjiYNJ(Vuno`KP@i29sX@h54B4gLILdK1Usq>sNcuq-V>^f!ggsJnK
zHh4}OJf}^bFm;}m!P7E$S|(4JI?ow{=ZwK~#^ec8=P3-H!r&=Po-lQu8G~oW;F&Rb
z!qj=%22b1IX`4J@>O5x+p0fteS(7JBo#&jvbI#y7XYz!p^PD$$&Ko@EO`b4yo>_xu
z*5H{ndBW6rE*Lx)44w-nPnbH-oWV0^@XVP!Vd^{=4W5ez&qb3bOr57=@N^8Gj>!|I
z&hv=D^N7Loh{+SC&U4A&xn%HMGI_$(c|yk2oF!+aqXy5TCQq0;&tnG9V+PM-CQq0;
z&le=J7|nz)NMtFR>|Rhv_nAq^a^!p5Kpr=c$4w+m9r>bxe9=I@Xd+?i$P)(ggn>L^
zB4O&tmki`f2J$5n2~$U&l*o9FKPi#%9Dh<F<B1z4A!8*uW#l|%<UD2OgsE~`5YVC~
zpw)IAsil~5l#w_RP#8$7j3kUWDFjsc$w9;!q2l&&Bvr0M0fiY;gMcdESU@#b5>Vwj
z6i}FGO)Q|wH?k-vqQ;6z$hgNyKw+Xq(iZ}%d?PF3D3K(f$~881o)AzKRw5ywnkxw?
z%vcpkKw-u_A)v}vA|arfD+#D_l{ra3Va7ZmpvqSwA)uNo38-?FND@$(F;57n@|8#k
zsOCxns$3<K1Qcd`Jt3gVS0W*xnkxyYa+OFDP?#}K2&nRvNC>FrN&>1}C6WXbX3P@;
zs(d990;;)^fGSssBmspP^MrsZUx|c(YOW-p%2gssKw-u_A)v}vA|arfD+#D_l}Hj$
zm@!WXsPdIa2&m>t0;*gkk^~fH%o75td?gYBs=1PYDp!dl0fia!gn%kviG+Y^t|Xw!
zRU%11Va7ZmpvqSwA)uNo38-?FND@$(F;57n@|8#ksOCxns$3<K1Qce>69TGyB@zOv
zxsre?SBWG6g&FgNfGS^!gn(+UB%sPwB1u4D#ylaQ%2y&GpqeWQsB)D^5>S{iPY9^;
zl}HGv=1KypTqTkO6lTm50;+r^5(28Zl7K2#i6jAq8S{jIDqo3&fNHKJpvqMuNkC!7
zJRzX4Gy#RB3n)xoKw)YEsv#ku8j=K5Ly~}MNC>Eggn(*D5>O3E0;(Y)pc)basv${0
zH6#hBhJ=7>NC>EgBmvcsB%m4+0tzd>x)4xUxMH$1NkC!ZGQ=h!<GzJ}!ixJA0tzec
zTM|&1ao>`F!o(iP@eU-E_3fT~SRK#<>7yz7DLRYw%Xt3p&)gAvJ8U3k1|s8}tzULq
zGmza@VPQ^WzCFce<W|CM_JHa{8pnEgXGhF4Dj`s-;O{r4q4ULfC&r#v`!5z!w-=Vg
z;<xA6OcDykFb6ZtrtCIz<~!|;A{$T>nyt%4XQ5NBx7l4Pi#=I0Pa7KK;kKlGw9{_2
z`GcLP4V0ehqwJ-T?EE>hm$d99nZ1Pe>Df!p<m@GX-y`m7F9y3%5qFVzj`XgU-j(Uy
zk@W5%>D?%Od4#;c4%i>u_hl`8S*9<Kq%R+mz8s~mjHXXLNBWAEz9Q3CM$%UfNneT5
zua2fqKS%miE&ZxYzdDkB^^o+dQTpm=`l;tgU)9oAW%}w!`syL+t5N#eX!_~rNMF;^
z*JS$INc!3#>1#-zqUmTfeO9H9Cl4$QaJ#F`NwdzGlD9m5=)R7^jo!v$!3>A>!dN&}
zH!<AUeVH@EVG%JFPSs5eH+G*bn&Ggr7z?NBCWafkZyYlmmK$T?RNcgIWB0)kGaS|+
zW8qZY#BgKdddUojg~?brRW~u**f>3EhQn%QES#z{!(}~7ZU0xSTC=hd4?m76k2d}N
zy;^g_V_11V`F)0A>pDyJ;@g$Aa=zIrck<48sXQUo1R+&*KMF)P=-Z$40@e$#A3I?E
zxlejs_WiES{_}s*1BfFejkebp#N0RW2tvUb9@em-?sTe6bscAmZnIt}6wb43<DzO}
zO<a2;8Sl3@Ta|X)T7fwNt(|q7SMs&@J_x^Y>#y@SufPA^t(#ld-)BB|n~h7+O*1P*
zm49x3ZgcxK*kM}7p8e;xu>E_lkx^uMw^>=^ZhfuI-In(@$Ig3!4y&9cUDqpPcRxp-
zNw-~T<l$Z}Zsf6TU0<tPA)`uv|KeNM<ck3`NHsEIvs|ENsMjiK=QVd@^{*0r(c59)
zbU}5OikyneyZuaWM<l4cvg_2Q@HU}1<G+0Ejg-!xc+u;C(Q33Iq!%Q;(G$ch6!Ulu
zFm|SKX%IMGn%F*HB0d@l5hliWs!ML$U9%3MVYzFScXEk?kZpy0`?E@}x6MPg9r7S#
z-OoJxd%b`^+!9GJ3%5pdO2(s=xLEz84@YZpxwd}TpXqhQ0rLDXoOHhb%2?OYcnG)d
zQzN_VRu|2B^k)Cun426ixUAIBv7W(6;BIZv>$plvy^o`Sn{11Q!WI(v%ah5C#X@^-
zZBFiIZ^m73Z`g<Q^W@<&79X7#?oQ~NP$Wic$@Ru)CAxWH>->-ZlEymS^^D&3U|?GV
z8s4}wyyC_}Mpz6R8njGy=J3LCBSU1^&h8CNa92I%f80pX9U|A!MgXi)hXFX30WzKF
z<}Gk77>|RAr2p|cMO(r46eXN})*M=M4#Oo9GMqgOClV0$xN#ye448Ia#GQ{htWznh
zuxPrXS%5}9L^-X^U|y}M6i~i&EMlfpvzT}NZ{E9kJHInFk*P^j&R|&k3wDfVuv(K|
zA2K11`TNC+nsyLbN%ctNa^3Ut+t>eYm!?I_E3dUg!oT;rcIl{16fx<wN{u`YH5?jL
zYM|7-+R6L(zB0kT$Sw%4((Z7N?h}vh0*_vJ`uAR$;GOhn>h#ttZ{yH*^A27?V*uc$
zq&6{9h>XuY`RcPc<)Q1ebGZNgm+9QW!DoN*Fd#%2P{96TPi4og6!1_s<<U~#>8a*W
zE!~u4-3&P9KngP8&YyZD0$SMcA9k1wnCVGQYQ~h_fm1x@LAo$SswTv~me)FecHxXD
zJoqx+7vrU$`S*KzIf}oyR#^uJcn~C@m_y4Os+dEurix!^RN~q%p%~RJdBv-d?{O4s
zAzdZ{QK3PBP-xT$K!pYcxk=SjAS@a3G@<*>L#m_mH_7I*azR$|4~8{VYS6hxzdYTe
zY7C&(nU&!y@*!oSN;HY0q<3aT2!!u|6N+=dM#UvGs1s6VIvrAQIvG+s=~Q%u2sSL9
zKkK}Lap>{U3lP%ij4x{7yoQ0bks5Q_r9l_opi!qnI;SyC3wUX6UQP@X3}5Af+jh!p
z7Vv2VtuYE8V)BX?9`;_mzNbM!=V8-O9?+PIY?`$O)MjZf(6o`H){%*c0|=U=s2Q>*
zO1C^rM;{}ok23xk>6{ZD?u=*^LNudQ2#U+Q+H7_vp3P`-p<6P$e)5`Hm#v<38)sGb
zhznMyR9d4SG&x@N(9DKaPtH!rFH7i<wAxpiO=h_ptp=mAE6XlEGoe{u`^*Fj$%)^Y
zsM^f0{(EQlXAiu8{o41BXW#ne{~h}E$*Di^>l1u$vO-OhpRG{q)b}X;a_Z28HZW(A
zm_A=QN4T@ZhYIHqz@-ma&T%>n-hDJ@e%5kfMs6sDxx}7a=B!OW?25hcqpnD>&G636
z?k2XL*j7K=+hSpEMtu@cX4_Q3hZRLsEcCWSVpvm(YLdem7fY$Tw>L$WVM)&JZ!;F&
z=_2<1ZO+2&`vEO#27!{8BO-TymL;(2XBY5KYK*n{dRkrXYTCt(YFywqnKPrtJvP1G
z?BL51yI)ZK^`rm2{@eff@!wwf(T#t$Gwa`JVUoYW2Ka)9_vd;y_#kH`crKM-JnJ1%
z>Low*kk1DfGvZ(3hA{S)Y)+LwwV&GDLOoaW?C;Rdr}ogEmDA5}<##*Lq$DsI(MB2l
zC7AI=kA+$4AJrN56XVQdocV5a=E>Ns{+Jd7@c5~Geu>=Z2WuB}mcQ?&unJJ0Q;n!F
z)oYI@c>dZbii{@i`KkOA$LB?Ojz~3Y&6etF`ZDR+A_1K=;ZbKi)?@pz&9P9({>e4m
zgzYn(+*FFzMkt@{<gAoPV5E_Cj?NH)?4Lio4F3M>tM9n#NqF{h#k+!)+X{J)v^bm2
zrs;tyTYX8+3EA}%bQS&mOuJC%Se;_I1vX!57rv?tTrtk@c-~$vL+z=s5*N-;!QY>6
zFGoQ5CRD{UaFY7QX|F!3IYke1_15Kt2!x$=Q)+6u_h)Y;sUhS^XE|+gVmtP7i4HCu
z$`-?u?BxoTSLsltL(TH{&t58((Ofn4Ch<T_tfME_W8z4a2P|NmSNS&E#_#EbyzZ}f
z>sN-TdF*ItC`+VI(|2S3{z{{{ff-)KPN7Gk1z5jozF9F_<sT+LOj_3IJsEk$UH68V
zG`uHco+h6rnRPlVF|W2Z++k}n$U~3aGIYp7#;wzgQ*-9qtHtQbBpAAqDoRmB5*1mS
N*0k6;sNmDM{|8%*0ha&(
literal 0
HcmV?d00001
diff --git a/tests/data/acpi/q35/HMAT.acpihmat-generic-x b/tests/data/acpi/q35/HMAT.acpihmat-generic-x
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..0e5765f6ee4c07638c70647ae145e968718b67cd 100644
GIT binary patch
literal 360
zcmeb9bqvX1WME+Ock*}k2v%^42yj*a0-z8Bhz+7)Km*7?=EKC%X^=V)XaHgs5CaPU
znNtB32dQC$vIW$k3?Kzk!wkf%P$3YX2`UEC0}=;`ae=W2gAr7W703dq;{anOBsL>h
pJ=k8L!N~R^yOS7uPXNsZ*=NL%!XOExQ-JsckOiV);t2K$1^{D&4*>uG
literal 0
HcmV?d00001
diff --git a/tests/data/acpi/q35/SRAT.acpihmat-generic-x b/tests/data/acpi/q35/SRAT.acpihmat-generic-x
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cbf45a31ba6d2c06f2bb0e203d4b40100522ac08 100644
GIT binary patch
literal 520
zcmWFzatz^MVqjoQbMklg2v%^42yj*a0!9V~1`r!WgD@Njp!1m-QRP{gkok-naGg*F
z7hC|lI-mt$@PQeo5LF!uOc=(1(J1c3v=^ogl^*QsSQQwc;R_2Fi2Gq-!luB$0E|8c
gN9O=f0|P@d2Z%I0EEqLdp(5~jn*bAl2QW|o04j0}0RR91
literal 0
HcmV?d00001
--
2.39.2
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 1/6] hw/acpi/GI: Fix trivial parameter alignment issue.
2024-04-03 10:29 ` [PATCH 1/6] hw/acpi/GI: Fix trivial parameter alignment issue Jonathan Cameron via
@ 2024-04-08 2:58 ` Ankit Agrawal
0 siblings, 0 replies; 15+ messages in thread
From: Ankit Agrawal @ 2024-04-08 2:58 UTC (permalink / raw)
To: Jonathan Cameron, marcel.apfelbaum@gmail.com, philmd@linaro.org,
mst@redhat.com, qemu-devel@nongnu.org
Cc: Dave Jiang, Huang Ying, Paolo Bonzini, eduardo@habkost.net,
imammedo@redhat.com, linux-cxl@vger.kernel.org,
linuxarm@huawei.com, Markus Armbruster, Michael Roth, Ani Sinha
> Before making additional modification, tidy up this misleading indentation.
Thanks for fixing it.
Reviewed-by: Ankit Agrawal <ankita@nvidia.com>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test.
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
` (5 preceding siblings ...)
2024-04-03 10:29 ` [PATCH 6/6] bios-tables-test: Add data for complex numa test (GI, GP etc) Jonathan Cameron via
@ 2024-04-12 7:39 ` Huang, Ying
6 siblings, 0 replies; 15+ messages in thread
From: Huang, Ying @ 2024-04-12 7:39 UTC (permalink / raw)
To: Jonathan Cameron
Cc: ankita, marcel.apfelbaum, philmd, mst, qemu-devel, Dave Jiang,
Paolo Bonzini, eduardo, imammedo, linux-cxl, linuxarm,
Markus Armbruster, Michael Roth, Ani Sinha
Hi, Jonathan,
Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
> ACPI 6.5 introduced Generic Port Affinity Structures to close a system
> description gap that was a problem for CXL memory systems.
> It defines an new SRAT Affinity structure (and hence allows creation of an
> ACPI Proximity Node which can only be defined via an SRAT structure)
> for the boundary between a discoverable fabric and a non discoverable
> system interconnects etc.
>
> The HMAT data on latency and bandwidth is combined with discoverable
> information from the CXL bus (link speeds, lane counts) and CXL devices
> (switch port to port characteristics and USP to memory, via CDAT tables
> read from the device). QEMU has supported the rest of the elements
> of this chain for a while but now the kernel has caught up and we need
> the missing element of Generic Ports (this code has been used extensively
> in testing and debugging that kernel support, some resulting fixes
> currently under review).
>
> Generic Port Affinity Structures are very similar to the recently
> added Generic Initiator Affinity Structures (GI) so this series
> factors out and reuses much of that infrastructure for reuse
> There are subtle differences (beyond the obvious structure ID change).
>
> - The ACPI spec example (and linux kernel support) has a Generic
> Port not as associated with the CXL root port, but rather with
> the CXL Host bridge. As a result, an ACPI handle is used (rather
> than the PCI SBDF option for GIs). In QEMU the easiest way
> to get to this is to target the root bridge PCI Bus, and
> conveniently the root bridge bus number is used for the UID allowing
> us to construct an appropriate entry.
>
> A key addition of this series is a complex NUMA topology example that
> stretches the QEMU emulation code for GI, GP and nodes with just
> CPUS, just memory, just hot pluggable memory, mixture of memory and CPUs.
>
> A similar test showed up a few NUMA related bugs with fixes applied for
> 9.0 (note that one of these needs linux booted to identify that it
> rejects the HMAT table and this test is a regression test for the
> table generation only).
>
> https://lore.kernel.org/qemu-devel/2eb6672cfdaea7dacd8e9bb0523887f13b9f85ce.1710282274.git.mst@redhat.com/
> https://lore.kernel.org/qemu-devel/74e2845c5f95b0c139c79233ddb65bb17f2dd679.1710282274.git.mst@redhat.com/
>
Thanks a lot for your work!
I need this to test some memory tiering kernel patches. I found the
following git branch,
https://gitlab.com/jic23/qemu/-/commits/cxl-2024-03-05/?ref_type=heads
Can I use that branch directly?
And, can you share an example qemu command line to setup Genport, CDAT,
and HMAT?
--
Best Regards,
Huang, Ying
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support
2024-04-03 10:29 ` [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support Jonathan Cameron via
@ 2024-04-23 10:56 ` Markus Armbruster
2024-04-29 17:50 ` Jonathan Cameron via
0 siblings, 1 reply; 15+ messages in thread
From: Markus Armbruster @ 2024-04-23 10:56 UTC (permalink / raw)
To: Jonathan Cameron
Cc: ankita, marcel.apfelbaum, philmd, mst, qemu-devel, Dave Jiang,
Huang Ying, Paolo Bonzini, eduardo, imammedo, linux-cxl, linuxarm,
Michael Roth, Ani Sinha
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
> 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
> up full latency and bandwidth numbers as need for work and data
> placement decisions.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> qapi/qom.json | 18 +++
> 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, 141 insertions(+), 38 deletions(-)
>
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 85e6b4f84a..5480d9ca24 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -826,6 +826,22 @@
> 'data': { 'pci-dev': 'str',
> 'node': 'uint32' } }
>
> +
> +##
> +# @AcpiGenericPortProperties:
> +#
> +# Properties for acpi-generic-port objects.
> +#
> +# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry
What's this exactly? A QOM path? A qdev ID? Something else?
> +#
> +# @node: numa node associated with the PCI device
NUMA
Is this a NUMA node ID?
> +#
> +# Since: 9.1
> +##
> +{ 'struct': 'AcpiGenericPortProperties',
> + 'data': { 'pci-bus': 'str',
> + 'node': 'uint32' } }
> +
> ##
> # @RngProperties:
> #
> @@ -944,6 +960,7 @@
> { 'enum': 'ObjectType',
> 'data': [
> 'acpi-generic-initiator',
> + 'acpi-generic-port',
> 'authz-list',
> 'authz-listfile',
> 'authz-pam',
> @@ -1016,6 +1033,7 @@
> 'discriminator': 'qom-type',
> 'data': {
> 'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
> + 'acpi-generic-port': 'AcpiGenericPortProperties',
> 'authz-list': 'AuthZListProperties',
> 'authz-listfile': 'AuthZListFileProperties',
> 'authz-pam': 'AuthZPAMProperties',
[...]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support
2024-04-23 10:56 ` Markus Armbruster
@ 2024-04-29 17:50 ` Jonathan Cameron via
2024-04-30 6:55 ` Markus Armbruster
0 siblings, 1 reply; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-29 17:50 UTC (permalink / raw)
To: Markus Armbruster
Cc: ankita, marcel.apfelbaum, philmd, mst, qemu-devel, Dave Jiang,
Huang Ying, Paolo Bonzini, eduardo, imammedo, linux-cxl, linuxarm,
Michael Roth, Ani Sinha
On Tue, 23 Apr 2024 12:56:21 +0200
Markus Armbruster <armbru@redhat.com> wrote:
> 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
> > 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
> > up full latency and bandwidth numbers as need for work and data
> > placement decisions.
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hi Markus,
I've again managed a bad job of defining an interface - thanks for
your help!
> > ---
> > qapi/qom.json | 18 +++
> > 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, 141 insertions(+), 38 deletions(-)
> >
> > diff --git a/qapi/qom.json b/qapi/qom.json
> > index 85e6b4f84a..5480d9ca24 100644
> > --- a/qapi/qom.json
> > +++ b/qapi/qom.json
> > @@ -826,6 +826,22 @@
> > 'data': { 'pci-dev': 'str',
> > 'node': 'uint32' } }
> >
> > +
> > +##
> > +# @AcpiGenericPortProperties:
> > +#
> > +# Properties for acpi-generic-port objects.
> > +#
> > +# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry
>
> What's this exactly? A QOM path? A qdev ID? Something else?
QOM path I believe as going to call object_resolve_path_type() on it.
Oddity is it's defined for the bus, not the host bridge that
we care about as the host bridge doesn't have a convenient id to let
us identify it.
e.g. It is specified via --device pxb-cxl,id=XXXX
of TYPE_PXB_CXL_HOST in the command line but ends up on the
TYPE_PCI_BUS with parent set to the PXB_CXL_HOST.
Normally we just want this bus for hanging root ports of it.
I can clarify it's the QOM path but I'm struggling a bit to explain
the relationship without resorting to an example.
This should also not mention SRAT as at some stage I'd expect DT
bindings to provide similar functionality.
>
> > +#
> > +# @node: numa node associated with the PCI device
>
> NUMA
>
> Is this a NUMA node ID?
Fair question with a non obvious answer. ACPI wise it's a proximity domain.
In every other SRAT entry (which define proximity domains) this does map
to a NUMA node in an operating system as they contain at least either some
form of memory access initiator (CPU, Generic Initiator etc) or a target (memory).
A Generic Port is subtly different in that it defines a proximity domain
that in of itself is not what we'd think of as a NUMA node but
rather an entity that exists to provide the info to the OS to stitch
together non discoverable and discoverable buses.
So I should have gone with something more specific. Could add this to
the parameter docs, or is it too much?
@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
discovered from firmware, and a discoverable bus. NUMA distances
and access characteristics are defined to and from that point,
but for system software to establish full initiator to target
characteristics this information must be combined with information
retrieved form the discoverable part of the path. An example would
use CDAT 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:
> > #
> > @@ -944,6 +960,7 @@
> > { 'enum': 'ObjectType',
> > 'data': [
> > 'acpi-generic-initiator',
> > + 'acpi-generic-port',
> > 'authz-list',
> > 'authz-listfile',
> > 'authz-pam',
> > @@ -1016,6 +1033,7 @@
> > 'discriminator': 'qom-type',
> > 'data': {
> > 'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
> > + 'acpi-generic-port': 'AcpiGenericPortProperties',
> > 'authz-list': 'AuthZListProperties',
> > 'authz-listfile': 'AuthZListFileProperties',
> > 'authz-pam': 'AuthZPAMProperties',
>
> [...]
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support
2024-04-29 17:50 ` Jonathan Cameron via
@ 2024-04-30 6:55 ` Markus Armbruster
2024-04-30 10:43 ` Jonathan Cameron via
0 siblings, 1 reply; 15+ messages in thread
From: Markus Armbruster @ 2024-04-30 6:55 UTC (permalink / raw)
To: Jonathan Cameron
Cc: ankita, marcel.apfelbaum, philmd, mst, qemu-devel, Dave Jiang,
Huang Ying, Paolo Bonzini, eduardo, imammedo, linux-cxl, linuxarm,
Michael Roth, Ani Sinha
Jonathan Cameron <Jonathan.Cameron@Huawei.com> writes:
> On Tue, 23 Apr 2024 12:56:21 +0200
> Markus Armbruster <armbru@redhat.com> wrote:
>
>> 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
>> > 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
>> > up full latency and bandwidth numbers as need for work and data
>> > placement decisions.
>> >
>> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Hi Markus,
>
> I've again managed a bad job of defining an interface - thanks for
> your help!
Good interfaces are hard!
>> > ---
>> > qapi/qom.json | 18 +++
>> > 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, 141 insertions(+), 38 deletions(-)
>> >
>> > diff --git a/qapi/qom.json b/qapi/qom.json
>> > index 85e6b4f84a..5480d9ca24 100644
>> > --- a/qapi/qom.json
>> > +++ b/qapi/qom.json
>> > @@ -826,6 +826,22 @@
>> > 'data': { 'pci-dev': 'str',
>> > 'node': 'uint32' } }
>> >
>> > +
>> > +##
>> > +# @AcpiGenericPortProperties:
>> > +#
>> > +# Properties for acpi-generic-port objects.
>> > +#
>> > +# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry
>>
>> What's this exactly? A QOM path? A qdev ID? Something else?
>
> QOM path I believe as going to call object_resolve_path_type() on it.
QOM path then.
> Oddity is it's defined for the bus, not the host bridge that
> we care about as the host bridge doesn't have a convenient id to let
> us identify it.
>
> e.g. It is specified via --device pxb-cxl,id=XXXX
> of TYPE_PXB_CXL_HOST in the command line but ends up on the
> TYPE_PCI_BUS with parent set to the PXB_CXL_HOST.
> Normally we just want this bus for hanging root ports of it.
>
> I can clarify it's the QOM path but I'm struggling a bit to explain
> the relationship without resorting to an example.
> This should also not mention SRAT as at some stage I'd expect DT
> bindings to provide similar functionality.
Let's start with an example. Not to put it into the doc comment, only
to help me understand what you need. Hopefully I can then assist with
improving the interface and/or its documentation.
>> > +#
>> > +# @node: numa node associated with the PCI device
>>
>> NUMA
>>
>> Is this a NUMA node ID?
>
> Fair question with a non obvious answer. ACPI wise it's a proximity domain.
> In every other SRAT entry (which define proximity domains) this does map
> to a NUMA node in an operating system as they contain at least either some
> form of memory access initiator (CPU, Generic Initiator etc) or a target (memory).
>
> A Generic Port is subtly different in that it defines a proximity domain
> that in of itself is not what we'd think of as a NUMA node but
> rather an entity that exists to provide the info to the OS to stitch
> together non discoverable and discoverable buses.
>
> So I should have gone with something more specific. Could add this to
> the parameter docs, or is it too much?
>
> @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
> discovered from firmware, and a discoverable bus. NUMA distances
> and access characteristics are defined to and from that point,
> but for system software to establish full initiator to target
> characteristics this information must be combined with information
> retrieved form the discoverable part of the path. An example would
> use CDAT information read from devices and switches in conjunction
> with link characteristics read from PCIe Configuration space.
This is mostly greek to me :) Bit I don't think it's too much.
>> > +#
>> > +# Since: 9.1
>> > +##
>> > +{ 'struct': 'AcpiGenericPortProperties',
>> > + 'data': { 'pci-bus': 'str',
>> > + 'node': 'uint32' } }
>> > +
>> > ##
>> > # @RngProperties:
>> > #
>> > @@ -944,6 +960,7 @@
>> > { 'enum': 'ObjectType',
>> > 'data': [
>> > 'acpi-generic-initiator',
>> > + 'acpi-generic-port',
>> > 'authz-list',
>> > 'authz-listfile',
>> > 'authz-pam',
>> > @@ -1016,6 +1033,7 @@
>> > 'discriminator': 'qom-type',
>> > 'data': {
>> > 'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
>> > + 'acpi-generic-port': 'AcpiGenericPortProperties',
>> > 'authz-list': 'AuthZListProperties',
>> > 'authz-listfile': 'AuthZListFileProperties',
>> > 'authz-pam': 'AuthZPAMProperties',
>>
>> [...]
>>
>>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support
2024-04-30 6:55 ` Markus Armbruster
@ 2024-04-30 10:43 ` Jonathan Cameron via
2024-06-04 12:06 ` Markus Armbruster
0 siblings, 1 reply; 15+ messages in thread
From: Jonathan Cameron via @ 2024-04-30 10:43 UTC (permalink / raw)
To: Markus Armbruster
Cc: ankita, marcel.apfelbaum, philmd, mst, qemu-devel, Dave Jiang,
Huang Ying, Paolo Bonzini, eduardo, imammedo, linux-cxl, linuxarm,
Michael Roth, Ani Sinha
On Tue, 30 Apr 2024 08:55:12 +0200
Markus Armbruster <armbru@redhat.com> wrote:
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> writes:
>
> > On Tue, 23 Apr 2024 12:56:21 +0200
> > Markus Armbruster <armbru@redhat.com> wrote:
> >
> >> 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
> >> > 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
> >> > up full latency and bandwidth numbers as need for work and data
> >> > placement decisions.
> >> >
> >> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Hi Markus,
> >
> > I've again managed a bad job of defining an interface - thanks for
> > your help!
>
> Good interfaces are hard!
>
> >> > ---
> >> > qapi/qom.json | 18 +++
> >> > 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, 141 insertions(+), 38 deletions(-)
> >> >
> >> > diff --git a/qapi/qom.json b/qapi/qom.json
> >> > index 85e6b4f84a..5480d9ca24 100644
> >> > --- a/qapi/qom.json
> >> > +++ b/qapi/qom.json
> >> > @@ -826,6 +826,22 @@
> >> > 'data': { 'pci-dev': 'str',
> >> > 'node': 'uint32' } }
> >> >
> >> > +
> >> > +##
> >> > +# @AcpiGenericPortProperties:
> >> > +#
> >> > +# Properties for acpi-generic-port objects.
> >> > +#
> >> > +# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry
> >>
> >> What's this exactly? A QOM path? A qdev ID? Something else?
> >
> > QOM path I believe as going to call object_resolve_path_type() on it.
>
> QOM path then.
>
> > Oddity is it's defined for the bus, not the host bridge that
> > we care about as the host bridge doesn't have a convenient id to let
> > us identify it.
> >
> > e.g. It is specified via --device pxb-cxl,id=XXXX
> > of TYPE_PXB_CXL_HOST in the command line but ends up on the
> > TYPE_PCI_BUS with parent set to the PXB_CXL_HOST.
> > Normally we just want this bus for hanging root ports of it.
> >
> > I can clarify it's the QOM path but I'm struggling a bit to explain
> > the relationship without resorting to an example.
> > This should also not mention SRAT as at some stage I'd expect DT
> > bindings to provide similar functionality.
>
> Let's start with an example. Not to put it into the doc comment, only
> to help me understand what you need. Hopefully I can then assist with
> improving the interface and/or its documentation.
Stripping out some relevant bits from a test setup and editing it down
- most of this is about creating relevant SLIT/HMAT tables.
# First a CXL root bridge, root port and direct attached device plus fixed
# memory window. Linux currently builds a NUMA node per fixed memory window
# but that's a simplification that may change over time.
-device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1,hdm_for_passthrough=true \
-device cxl-rp,port=0,bus=cxl.1,id=cxl_rp_port0,chassis=0,slot=2 \
-device cxl-type3,bus=cxl_rp_port0,volatile-memdev=cxl-mem1,persistent-memdev=cxl-mem2,id=cxl-pmem1,lsa=cxl-lsa1,sn=3 \
-machine cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=1k \
# Next line is the port defintion - see that the pci-bus refers to the one in the id parameter for
# the PXB CXL, but the ACPI table that is generated refers to the DSDT entry via a ACPI0016 entry.
# So to get to that we use the PCI bus ID of the root bus that forms part of the root bridge (but
# is a child object in qemu.
-numa node,nodeid=2 \
-object acpi-generic-port,id=bob11,pci-bus=cxl.1,node=2 \
# The rest is a the setup for the hmat and slit tables. I hid most of the config, but
# left this here as key is that we specify values to and from the generic port 'node'
# but it's not really a node as such, but just a point along the path to one.
-numa dist,src=0,dst=0,val=10 -numa dist,src=0,dst=1,val=21 -numa dist,src=0,dst=2,val=21 -numa dist,src=0,dst=3,val=21 -numa dist,src=0,dst=4,val=21 -numa dist,src=0,dst=5,val=21 \
-numa dist,src=1,dst=0,val=21 -numa dist,src=1,dst=1,val=10 -numa dist,src=1,dst=2,val=21 -numa dist,src=1,dst=3,val=21 -numa dist,src=1,dst=4,val=21 -numa dist,src=1,dst=5,val=21 \
-numa dist,src=2,dst=0,val=21 -numa dist,src=2,dst=1,val=21 -numa dist,src=2,dst=2,val=10 -numa dist,src=2,dst=3,val=21 -numa dist,src=2,dst=4,val=21 -numa dist,src=2,dst=5,val=21 \
-numa dist,src=3,dst=0,val=21 -numa dist,src=3,dst=1,val=21 -numa dist,src=3,dst=2,val=21 -numa dist,src=3,dst=3,val=10 -numa dist,src=3,dst=4,val=21 -numa dist,src=3,dst=5,val=21 \
-numa dist,src=4,dst=0,val=21 -numa dist,src=4,dst=1,val=21 -numa dist,src=4,dst=2,val=21 -numa dist,src=4,dst=3,val=21 -numa dist,src=4,dst=4,val=10 -numa dist,src=4,dst=5,val=21 \
-numa dist,src=5,dst=0,val=21 -numa dist,src=5,dst=1,val=21 -numa dist,src=5,dst=2,val=21 -numa dist,src=5,dst=3,val=21 -numa dist,src=5,dst=4,val=21 -numa dist,src=5,dst=5,val=10 \
-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=10 \
-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M \
-numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-latency,latency=100 \
-numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
-numa hmat-lb,initiator=0,target=4,hierarchy=memory,data-type=access-latency,latency=100 \
-numa hmat-lb,initiator=0,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
-numa hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-latency,latency=200 \
-numa hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=500 \
-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M \
-numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-latency,latency=50 \
-numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
-numa hmat-lb,initiator=1,target=4,hierarchy=memory,data-type=access-latency,latency=50 \
-numa hmat-lb,initiator=1,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M \
-numa hmat-lb,initiator=1,target=5,hierarchy=memory,data-type=access-latency,latency=500 \
-numa hmat-lb,initiator=1,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M \
-numa hmat-lb,initiator=3,target=0,hierarchy=memory,data-type=access-latency,latency=20 \
-numa hmat-lb,initiator=3,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
-numa hmat-lb,initiator=3,target=2,hierarchy=memory,data-type=access-latency,latency=80 \
-numa hmat-lb,initiator=3,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
-numa hmat-lb,initiator=3,target=4,hierarchy=memory,data-type=access-latency,latency=80 \
-numa hmat-lb,initiator=3,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
-numa hmat-lb,initiator=3,target=5,hierarchy=memory,data-type=access-latency,latency=20 \
-numa hmat-lb,initiator=3,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
-numa hmat-lb,initiator=5,target=0,hierarchy=memory,data-type=access-latency,latency=20 \
-numa hmat-lb,initiator=5,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
-numa hmat-lb,initiator=5,target=2,hierarchy=memory,data-type=access-latency,latency=80 \
-numa hmat-lb,initiator=5,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
-numa hmat-lb,initiator=5,target=4,hierarchy=memory,data-type=access-latency,latency=80 \
-numa hmat-lb,initiator=5,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
-numa hmat-lb,initiator=5,target=5,hierarchy=memory,data-type=access-latency,latency=10 \
-numa hmat-lb,initiator=5,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M
>
> >> > +#
> >> > +# @node: numa node associated with the PCI device
> >>
> >> NUMA
> >>
> >> Is this a NUMA node ID?
> >
> > Fair question with a non obvious answer. ACPI wise it's a proximity domain.
> > In every other SRAT entry (which define proximity domains) this does map
> > to a NUMA node in an operating system as they contain at least either some
> > form of memory access initiator (CPU, Generic Initiator etc) or a target (memory).
> >
> > A Generic Port is subtly different in that it defines a proximity domain
> > that in of itself is not what we'd think of as a NUMA node but
> > rather an entity that exists to provide the info to the OS to stitch
> > together non discoverable and discoverable buses.
> >
> > So I should have gone with something more specific. Could add this to
> > the parameter docs, or is it too much?
> >
> > @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
> > discovered from firmware, and a discoverable bus. NUMA distances
> > and access characteristics are defined to and from that point,
> > but for system software to establish full initiator to target
> > characteristics this information must be combined with information
> > retrieved form the discoverable part of the path. An example would
> > use CDAT information read from devices and switches in conjunction
> > with link characteristics read from PCIe Configuration space.
>
> This is mostly greek to me :) Bit I don't think it's too much.
>
> >> > +#
> >> > +# Since: 9.1
> >> > +##
> >> > +{ 'struct': 'AcpiGenericPortProperties',
> >> > + 'data': { 'pci-bus': 'str',
> >> > + 'node': 'uint32' } }
> >> > +
> >> > ##
> >> > # @RngProperties:
> >> > #
> >> > @@ -944,6 +960,7 @@
> >> > { 'enum': 'ObjectType',
> >> > 'data': [
> >> > 'acpi-generic-initiator',
> >> > + 'acpi-generic-port',
> >> > 'authz-list',
> >> > 'authz-listfile',
> >> > 'authz-pam',
> >> > @@ -1016,6 +1033,7 @@
> >> > 'discriminator': 'qom-type',
> >> > 'data': {
> >> > 'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
> >> > + 'acpi-generic-port': 'AcpiGenericPortProperties',
> >> > 'authz-list': 'AuthZListProperties',
> >> > 'authz-listfile': 'AuthZListFileProperties',
> >> > 'authz-pam': 'AuthZPAMProperties',
> >>
> >> [...]
> >>
> >>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support
2024-04-30 10:43 ` Jonathan Cameron via
@ 2024-06-04 12:06 ` Markus Armbruster
2024-06-04 13:42 ` Jonathan Cameron via
0 siblings, 1 reply; 15+ messages in thread
From: Markus Armbruster @ 2024-06-04 12:06 UTC (permalink / raw)
To: Jonathan Cameron
Cc: ankita, marcel.apfelbaum, philmd, mst, qemu-devel, Dave Jiang,
Huang Ying, Paolo Bonzini, eduardo, imammedo, linux-cxl, linuxarm,
Michael Roth, Ani Sinha
Sorry for the late reply. I had to put this aside, and I'm coming back
to it only now.
Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
> On Tue, 30 Apr 2024 08:55:12 +0200
> Markus Armbruster <armbru@redhat.com> wrote:
>
>> Jonathan Cameron <Jonathan.Cameron@Huawei.com> writes:
>>
>> > On Tue, 23 Apr 2024 12:56:21 +0200
>> > Markus Armbruster <armbru@redhat.com> wrote:
>> >
>> >> 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
>> >> > 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
>> >> > up full latency and bandwidth numbers as need for work and data
>> >> > placement decisions.
>> >> >
>> >> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> >
>> > Hi Markus,
>> >
>> > I've again managed a bad job of defining an interface - thanks for
>> > your help!
>>
>> Good interfaces are hard!
>>
>> >> > ---
>> >> > qapi/qom.json | 18 +++
>> >> > 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, 141 insertions(+), 38 deletions(-)
>> >> >
>> >> > diff --git a/qapi/qom.json b/qapi/qom.json
>> >> > index 85e6b4f84a..5480d9ca24 100644
>> >> > --- a/qapi/qom.json
>> >> > +++ b/qapi/qom.json
>> >> > @@ -826,6 +826,22 @@
>> >> > 'data': { 'pci-dev': 'str',
>> >> > 'node': 'uint32' } }
>> >> >
>> >> > +
>> >> > +##
>> >> > +# @AcpiGenericPortProperties:
>> >> > +#
>> >> > +# Properties for acpi-generic-port objects.
>> >> > +#
>> >> > +# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry
>> >>
>> >> What's this exactly? A QOM path? A qdev ID? Something else?
>> >
>> > QOM path I believe as going to call object_resolve_path_type() on it.
>>
>> QOM path then.
>>
>> > Oddity is it's defined for the bus, not the host bridge that
>> > we care about as the host bridge doesn't have a convenient id to let
>> > us identify it.
Copied from the example below:
-object acpi-generic-port,id=bob11,pci-bus=cxl.1,node=2
where pci-bus=cxl.1 refers to
-device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1,hdm_for_passthrough=true
What is "the host bridge that we care about" in that example?
Is pci-bus=cxl.1 a surrogate for a reference to "the host bridge that we
care about"? I.e. something that enables the C code to find the host
bridge?
>> > e.g. It is specified via --device pxb-cxl,id=XXXX
>> > of TYPE_PXB_CXL_HOST in the command line but ends up on the
>> > TYPE_PCI_BUS with parent set to the PXB_CXL_HOST.
>> > Normally we just want this bus for hanging root ports of it.
>> >
>> > I can clarify it's the QOM path but I'm struggling a bit to explain
>> > the relationship without resorting to an example.
>> > This should also not mention SRAT as at some stage I'd expect DT
>> > bindings to provide similar functionality.
>>
>> Let's start with an example. Not to put it into the doc comment, only
>> to help me understand what you need. Hopefully I can then assist with
>> improving the interface and/or its documentation.
>
> Stripping out some relevant bits from a test setup and editing it down
> - most of this is about creating relevant SLIT/HMAT tables.
>
> # First a CXL root bridge, root port and direct attached device plus fixed
> # memory window. Linux currently builds a NUMA node per fixed memory window
> # but that's a simplification that may change over time.
> -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1,hdm_for_passthrough=true \
> -device cxl-rp,port=0,bus=cxl.1,id=cxl_rp_port0,chassis=0,slot=2 \
> -device cxl-type3,bus=cxl_rp_port0,volatile-memdev=cxl-mem1,persistent-memdev=cxl-mem2,id=cxl-pmem1,lsa=cxl-lsa1,sn=3 \
> -machine cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=1k \
>
> # Next line is the port defintion - see that the pci-bus refers to the one in the id parameter for
> # the PXB CXL, but the ACPI table that is generated refers to the DSDT entry via a ACPI0016 entry.
> # So to get to that we use the PCI bus ID of the root bus that forms part of the root bridge (but
> # is a child object in qemu.
> -numa node,nodeid=2 \
> -object acpi-generic-port,id=bob11,pci-bus=cxl.1,node=2 \
>
> # The rest is a the setup for the hmat and slit tables. I hid most of the config, but
> # left this here as key is that we specify values to and from the generic port 'node'
> # but it's not really a node as such, but just a point along the path to one.
>
> -numa dist,src=0,dst=0,val=10 -numa dist,src=0,dst=1,val=21 -numa dist,src=0,dst=2,val=21 -numa dist,src=0,dst=3,val=21 -numa dist,src=0,dst=4,val=21 -numa dist,src=0,dst=5,val=21 \
> -numa dist,src=1,dst=0,val=21 -numa dist,src=1,dst=1,val=10 -numa dist,src=1,dst=2,val=21 -numa dist,src=1,dst=3,val=21 -numa dist,src=1,dst=4,val=21 -numa dist,src=1,dst=5,val=21 \
> -numa dist,src=2,dst=0,val=21 -numa dist,src=2,dst=1,val=21 -numa dist,src=2,dst=2,val=10 -numa dist,src=2,dst=3,val=21 -numa dist,src=2,dst=4,val=21 -numa dist,src=2,dst=5,val=21 \
> -numa dist,src=3,dst=0,val=21 -numa dist,src=3,dst=1,val=21 -numa dist,src=3,dst=2,val=21 -numa dist,src=3,dst=3,val=10 -numa dist,src=3,dst=4,val=21 -numa dist,src=3,dst=5,val=21 \
> -numa dist,src=4,dst=0,val=21 -numa dist,src=4,dst=1,val=21 -numa dist,src=4,dst=2,val=21 -numa dist,src=4,dst=3,val=21 -numa dist,src=4,dst=4,val=10 -numa dist,src=4,dst=5,val=21 \
> -numa dist,src=5,dst=0,val=21 -numa dist,src=5,dst=1,val=21 -numa dist,src=5,dst=2,val=21 -numa dist,src=5,dst=3,val=21 -numa dist,src=5,dst=4,val=21 -numa dist,src=5,dst=5,val=10 \
> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=10 \
> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M \
> -numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-latency,latency=100 \
> -numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> -numa hmat-lb,initiator=0,target=4,hierarchy=memory,data-type=access-latency,latency=100 \
> -numa hmat-lb,initiator=0,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> -numa hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-latency,latency=200 \
> -numa hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=500 \
> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M \
> -numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-latency,latency=50 \
> -numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> -numa hmat-lb,initiator=1,target=4,hierarchy=memory,data-type=access-latency,latency=50 \
> -numa hmat-lb,initiator=1,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M \
> -numa hmat-lb,initiator=1,target=5,hierarchy=memory,data-type=access-latency,latency=500 \
> -numa hmat-lb,initiator=1,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M \
> -numa hmat-lb,initiator=3,target=0,hierarchy=memory,data-type=access-latency,latency=20 \
> -numa hmat-lb,initiator=3,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> -numa hmat-lb,initiator=3,target=2,hierarchy=memory,data-type=access-latency,latency=80 \
> -numa hmat-lb,initiator=3,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> -numa hmat-lb,initiator=3,target=4,hierarchy=memory,data-type=access-latency,latency=80 \
> -numa hmat-lb,initiator=3,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> -numa hmat-lb,initiator=3,target=5,hierarchy=memory,data-type=access-latency,latency=20 \
> -numa hmat-lb,initiator=3,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> -numa hmat-lb,initiator=5,target=0,hierarchy=memory,data-type=access-latency,latency=20 \
> -numa hmat-lb,initiator=5,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> -numa hmat-lb,initiator=5,target=2,hierarchy=memory,data-type=access-latency,latency=80 \
> -numa hmat-lb,initiator=5,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> -numa hmat-lb,initiator=5,target=4,hierarchy=memory,data-type=access-latency,latency=80 \
> -numa hmat-lb,initiator=5,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> -numa hmat-lb,initiator=5,target=5,hierarchy=memory,data-type=access-latency,latency=10 \
> -numa hmat-lb,initiator=5,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M
Uff!
Could you throw in output of "info qom-tree /"?
[...]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support
2024-06-04 12:06 ` Markus Armbruster
@ 2024-06-04 13:42 ` Jonathan Cameron via
0 siblings, 0 replies; 15+ messages in thread
From: Jonathan Cameron via @ 2024-06-04 13:42 UTC (permalink / raw)
To: Markus Armbruster
Cc: ankita, marcel.apfelbaum, philmd, mst, qemu-devel, Dave Jiang,
Huang Ying, Paolo Bonzini, eduardo, imammedo, linux-cxl, linuxarm,
Michael Roth, Ani Sinha
On Tue, 04 Jun 2024 14:06:53 +0200
Markus Armbruster <armbru@redhat.com> wrote:
> Sorry for the late reply. I had to put this aside, and I'm coming back
> to it only now.
No problem. Thanks for looking again!
>
> Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
>
> > On Tue, 30 Apr 2024 08:55:12 +0200
> > Markus Armbruster <armbru@redhat.com> wrote:
> >
> >> Jonathan Cameron <Jonathan.Cameron@Huawei.com> writes:
> >>
> >> > On Tue, 23 Apr 2024 12:56:21 +0200
> >> > Markus Armbruster <armbru@redhat.com> wrote:
> >> >
> >> >> 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
> >> >> > 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
> >> >> > up full latency and bandwidth numbers as need for work and data
> >> >> > placement decisions.
> >> >> >
> >> >> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >> >
> >> > Hi Markus,
> >> >
> >> > I've again managed a bad job of defining an interface - thanks for
> >> > your help!
> >>
> >> Good interfaces are hard!
> >>
> >> >> > ---
> >> >> > qapi/qom.json | 18 +++
> >> >> > 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, 141 insertions(+), 38 deletions(-)
> >> >> >
> >> >> > diff --git a/qapi/qom.json b/qapi/qom.json
> >> >> > index 85e6b4f84a..5480d9ca24 100644
> >> >> > --- a/qapi/qom.json
> >> >> > +++ b/qapi/qom.json
> >> >> > @@ -826,6 +826,22 @@
> >> >> > 'data': { 'pci-dev': 'str',
> >> >> > 'node': 'uint32' } }
> >> >> >
> >> >> > +
> >> >> > +##
> >> >> > +# @AcpiGenericPortProperties:
> >> >> > +#
> >> >> > +# Properties for acpi-generic-port objects.
> >> >> > +#
> >> >> > +# @pci-bus: PCI bus of the hostbridge associated with this SRAT entry
> >> >>
> >> >> What's this exactly? A QOM path? A qdev ID? Something else?
> >> >
> >> > QOM path I believe as going to call object_resolve_path_type() on it.
> >>
> >> QOM path then.
> >>
> >> > Oddity is it's defined for the bus, not the host bridge that
> >> > we care about as the host bridge doesn't have a convenient id to let
> >> > us identify it.
>
> Copied from the example below:
>
> -object acpi-generic-port,id=bob11,pci-bus=cxl.1,node=2
>
> where pci-bus=cxl.1 refers to
>
> -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1,hdm_for_passthrough=true
>
> What is "the host bridge that we care about" in that example?
>
> Is pci-bus=cxl.1 a surrogate for a reference to "the host bridge that we
> care about"? I.e. something that enables the C code to find the host
> bridge?
>
Yes, That pci-bridge line results in the creation of two objects.
A host bridge and a bus below it (to which root ports etc are attached).
ID is associated with the bus.
As you say we are using it as a surrogate to get to the host bridge as
they always have a 1:1 relationship.
Why the ACPI spec defines the generic port as not refering to a port
but to a host bridge is beyond me, but unfortunately it does have
an explicit reference to that being the right thing to do in this case.
> >> > e.g. It is specified via --device pxb-cxl,id=XXXX
> >> > of TYPE_PXB_CXL_HOST in the command line but ends up on the
> >> > TYPE_PCI_BUS with parent set to the PXB_CXL_HOST.
> >> > Normally we just want this bus for hanging root ports of it.
> >> >
> >> > I can clarify it's the QOM path but I'm struggling a bit to explain
> >> > the relationship without resorting to an example.
> >> > This should also not mention SRAT as at some stage I'd expect DT
> >> > bindings to provide similar functionality.
> >>
> >> Let's start with an example. Not to put it into the doc comment, only
> >> to help me understand what you need. Hopefully I can then assist with
> >> improving the interface and/or its documentation.
> >
> > Stripping out some relevant bits from a test setup and editing it down
> > - most of this is about creating relevant SLIT/HMAT tables.
> >
> > # First a CXL root bridge, root port and direct attached device plus fixed
> > # memory window. Linux currently builds a NUMA node per fixed memory window
> > # but that's a simplification that may change over time.
> > -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1,hdm_for_passthrough=true \
> > -device cxl-rp,port=0,bus=cxl.1,id=cxl_rp_port0,chassis=0,slot=2 \
> > -device cxl-type3,bus=cxl_rp_port0,volatile-memdev=cxl-mem1,persistent-memdev=cxl-mem2,id=cxl-pmem1,lsa=cxl-lsa1,sn=3 \
> > -machine cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=1k \
> >
> > # Next line is the port defintion - see that the pci-bus refers to the one in the id parameter for
> > # the PXB CXL, but the ACPI table that is generated refers to the DSDT entry via a ACPI0016 entry.
> > # So to get to that we use the PCI bus ID of the root bus that forms part of the root bridge (but
> > # is a child object in qemu.
> > -numa node,nodeid=2 \
> > -object acpi-generic-port,id=bob11,pci-bus=cxl.1,node=2 \
> >
> > # The rest is a the setup for the hmat and slit tables. I hid most of the config, but
> > # left this here as key is that we specify values to and from the generic port 'node'
> > # but it's not really a node as such, but just a point along the path to one.
> >
> > -numa dist,src=0,dst=0,val=10 -numa dist,src=0,dst=1,val=21 -numa dist,src=0,dst=2,val=21 -numa dist,src=0,dst=3,val=21 -numa dist,src=0,dst=4,val=21 -numa dist,src=0,dst=5,val=21 \
> > -numa dist,src=1,dst=0,val=21 -numa dist,src=1,dst=1,val=10 -numa dist,src=1,dst=2,val=21 -numa dist,src=1,dst=3,val=21 -numa dist,src=1,dst=4,val=21 -numa dist,src=1,dst=5,val=21 \
> > -numa dist,src=2,dst=0,val=21 -numa dist,src=2,dst=1,val=21 -numa dist,src=2,dst=2,val=10 -numa dist,src=2,dst=3,val=21 -numa dist,src=2,dst=4,val=21 -numa dist,src=2,dst=5,val=21 \
> > -numa dist,src=3,dst=0,val=21 -numa dist,src=3,dst=1,val=21 -numa dist,src=3,dst=2,val=21 -numa dist,src=3,dst=3,val=10 -numa dist,src=3,dst=4,val=21 -numa dist,src=3,dst=5,val=21 \
> > -numa dist,src=4,dst=0,val=21 -numa dist,src=4,dst=1,val=21 -numa dist,src=4,dst=2,val=21 -numa dist,src=4,dst=3,val=21 -numa dist,src=4,dst=4,val=10 -numa dist,src=4,dst=5,val=21 \
> > -numa dist,src=5,dst=0,val=21 -numa dist,src=5,dst=1,val=21 -numa dist,src=5,dst=2,val=21 -numa dist,src=5,dst=3,val=21 -numa dist,src=5,dst=4,val=21 -numa dist,src=5,dst=5,val=10 \
> > -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=10 \
> > -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M \
> > -numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-latency,latency=100 \
> > -numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> > -numa hmat-lb,initiator=0,target=4,hierarchy=memory,data-type=access-latency,latency=100 \
> > -numa hmat-lb,initiator=0,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> > -numa hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-latency,latency=200 \
> > -numa hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> > -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=500 \
> > -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M \
> > -numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-latency,latency=50 \
> > -numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> > -numa hmat-lb,initiator=1,target=4,hierarchy=memory,data-type=access-latency,latency=50 \
> > -numa hmat-lb,initiator=1,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M \
> > -numa hmat-lb,initiator=1,target=5,hierarchy=memory,data-type=access-latency,latency=500 \
> > -numa hmat-lb,initiator=1,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M \
> > -numa hmat-lb,initiator=3,target=0,hierarchy=memory,data-type=access-latency,latency=20 \
> > -numa hmat-lb,initiator=3,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> > -numa hmat-lb,initiator=3,target=2,hierarchy=memory,data-type=access-latency,latency=80 \
> > -numa hmat-lb,initiator=3,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> > -numa hmat-lb,initiator=3,target=4,hierarchy=memory,data-type=access-latency,latency=80 \
> > -numa hmat-lb,initiator=3,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> > -numa hmat-lb,initiator=3,target=5,hierarchy=memory,data-type=access-latency,latency=20 \
> > -numa hmat-lb,initiator=3,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> > -numa hmat-lb,initiator=5,target=0,hierarchy=memory,data-type=access-latency,latency=20 \
> > -numa hmat-lb,initiator=5,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=400M \
> > -numa hmat-lb,initiator=5,target=2,hierarchy=memory,data-type=access-latency,latency=80 \
> > -numa hmat-lb,initiator=5,target=4,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> > -numa hmat-lb,initiator=5,target=4,hierarchy=memory,data-type=access-latency,latency=80 \
> > -numa hmat-lb,initiator=5,target=2,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M \
> > -numa hmat-lb,initiator=5,target=5,hierarchy=memory,data-type=access-latency,latency=10 \
> > -numa hmat-lb,initiator=5,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=800M
>
> Uff!
>
> Could you throw in output of "info qom-tree /"?
>
This isn't exactly the setup above, but I happen to have it running and it's
hopefully close enough. I've tried to crop only the definitely irrelevant parts
out. I'm having one of those days where for some reason my terminal is
messing up whitespace. Hopefully reconstructed correctly enough.
Deep in here you'll see
/device[64] (pxb-cxl-host)
/.cache_mem[0] (memory-region)
/.io[0] (memory-region)
/cxl.1 (pxb-cxl-bus)
/pxb-cxl-host[0] (memory-region)
which is what I want to get and
/cxl.1 (pxb-cxl)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
which is what I can get.
Anyhow lots more follows.
/(container)
...
/machine (virt-9.1-machine)
/cxl-fixed-memory-region[0] (memory-region)
/cxl-fixed-memory-region[1] (memory-region)
/cxl_host_reg[0] (memory-region)
...
/peripheral (container)
...
/cxl-pmem1 (cxl-type3)
/.cache_mem[0] (memory-region)
/.io[0] (memory-region)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/cap-array[0] (memory-region)
/cpmu0-registers[0] (memory-region)
/cpmu1-registers[0] (memory-region)
/cxl-type3-msix[0] (memory-region)
/cxl-type3[0] (memory-region)
/device-registers[0] (memory-region)
/device-status[0] (memory-region)
/mailbox[0] (memory-region)
/memory device caps[0] (memory-region)
/msix-pba[0] (memory-region)
/msix-table[0] (memory-region)
/cxl-pmem2 (cxl-type3)
/.cache_mem[0] (memory-region)
/.io[0] (memory-region)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/cap-array[0] (memory-region)
/cpmu0-registers[0] (memory-region)
/cpmu1-registers[0] (memory-region)
/cxl-type3-msix[0] (memory-region)
/cxl-type3[0] (memory-region)
/device-registers[0] (memory-region)
/device-status[0] (memory-region)
/mailbox[0] (memory-region)
/memory device caps[0] (memory-region)
/msix-pba[0] (memory-region)
/msix-table[0] (memory-region)
/cxl.1 (pxb-cxl)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/cxl_rp_port0 (cxl-rp)
/.cache_mem[0] (memory-region)
/.io[0] (memory-region)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/cpmu0-registers[0] (memory-region)
/cxl-rp[0] (memory-region)
/cxl_rp_port0 (CXL)
/pci_bridge_io[0] (memory-region)
/pci_bridge_io[1] (memory-region)
/pci_bridge_mem[0] (memory-region)
/pci_bridge_pci[0] (memory-region)
/pci_bridge_pref_mem[0] (memory-region)
/pci_bridge_vga_io_hi[0] (memory-region)
/pci_bridge_vga_io_lo[0] (memory-region)
/pci_bridge_vga_mem[0] (memory-region)
/registers[0] (memory-region)
/cxl_rp_port1 (cxl-rp)
/.cache_mem[0] (memory-region)
/.io[0] (memory-region)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/cpmu0-registers[0] (memory-region)
/cxl-rp[0] (memory-region)
/cxl_rp_port1 (CXL)
/pci_bridge_io[0] (memory-region)
/pci_bridge_io[1] (memory-region)
/pci_bridge_mem[0] (memory-region)
/pci_bridge_pci[0] (memory-region)
/pci_bridge_pref_mem[0] (memory-region)
/pci_bridge_vga_io_hi[0] (memory-region)
/pci_bridge_vga_io_lo[0] (memory-region)
/pci_bridge_vga_mem[0] (memory-region)
/registers[0] (memory-region)
...
/unattached (container)
....
/device[64] (pxb-cxl-host)
/.cache_mem[0] (memory-region)
/.io[0] (memory-region)
/cxl.1 (pxb-cxl-bus)
/pxb-cxl-host[0] (memory-region)
...
/device[8] (gpex-pcihost)
/gpex_ioport[0] (memory-region)
/gpex_ioport_window[0] (memory-region)
/gpex_mmio[0] (memory-region)
/gpex_mmio_window[0] (memory-region)
/gpex_root (gpex-root)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/pcie-ecam[0] (memory-region)
/pcie-mmcfg-mmio[0] (memory-region)
/pcie-mmio-high[0] (memory-region)
/pcie-mmio[0] (memory-region)
/pcie.0 (PCIE)
...
/objects (container)
/bob11 (acpi-generic-port)
/bob2 (acpi-generic-initiator
/cxl-lsa1 (memory-backend-file)
/cxl-lsa1[0] (memory-region)
/cxl-lsa2 (memory-backend-file)
/cxl-lsa2[0] (memory-region)
/cxl-mem1 (memory-backend-file)
/cxl-mem1[0] (memory-region)
/cxl-mem2 (memory-backend-file)
/cxl-mem2[0] (memory-region)
/cxl-mem3 (memory-backend-file)
/cxl-mem3[0] (memory-region)
/cxl-mem4 (memory-backend-file)
/cxl-mem4[0] (memory-region)
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-06-04 13:44 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-03 10:29 [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 1/6] hw/acpi/GI: Fix trivial parameter alignment issue Jonathan Cameron via
2024-04-08 2:58 ` Ankit Agrawal
2024-04-03 10:29 ` [PATCH 2/6] hw/acpi: Insert an acpi-generic-node base under acpi-generic-initiator Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 3/6] hw/acpi: Generic Port Affinity Structure support Jonathan Cameron via
2024-04-23 10:56 ` Markus Armbruster
2024-04-29 17:50 ` Jonathan Cameron via
2024-04-30 6:55 ` Markus Armbruster
2024-04-30 10:43 ` Jonathan Cameron via
2024-06-04 12:06 ` Markus Armbruster
2024-06-04 13:42 ` Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 4/6] bios-tables-test: Allow for new acpihmat-generic-x test data Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 5/6] bios-tables-test: Add complex SRAT / HMAT test for GI GP Jonathan Cameron via
2024-04-03 10:29 ` [PATCH 6/6] bios-tables-test: Add data for complex numa test (GI, GP etc) Jonathan Cameron via
2024-04-12 7:39 ` [PATCH 0/6 qemu] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Huang, Ying
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).