2020-09-01 15:56:39 +03:00
|
|
|
/*
|
|
|
|
* QEMU PowerPC pSeries Logical Partition NUMA associativity handling
|
|
|
|
*
|
|
|
|
* Copyright IBM Corp. 2020
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Daniel Henrique Barboza <danielhb413@gmail.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu/osdep.h"
|
|
|
|
#include "hw/ppc/spapr_numa.h"
|
2020-09-04 01:06:36 +03:00
|
|
|
#include "hw/pci-host/spapr.h"
|
2020-09-01 15:56:39 +03:00
|
|
|
#include "hw/ppc/fdt.h"
|
|
|
|
|
2020-09-04 01:06:36 +03:00
|
|
|
/* Moved from hw/ppc/spapr_pci_nvlink2.c */
|
|
|
|
#define SPAPR_GPU_NUMA_ID (cpu_to_be32(1))
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
|
2021-09-20 20:49:43 +03:00
|
|
|
/*
|
|
|
|
* Retrieves max_dist_ref_points of the current NUMA affinity.
|
|
|
|
*/
|
|
|
|
static int get_max_dist_ref_points(SpaprMachineState *spapr)
|
|
|
|
{
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
if (spapr_ovec_test(spapr->ov5_cas, OV5_FORM2_AFFINITY)) {
|
|
|
|
return FORM2_DIST_REF_POINTS;
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:43 +03:00
|
|
|
return FORM1_DIST_REF_POINTS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieves numa_assoc_size of the current NUMA affinity.
|
|
|
|
*/
|
|
|
|
static int get_numa_assoc_size(SpaprMachineState *spapr)
|
|
|
|
{
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
if (spapr_ovec_test(spapr->ov5_cas, OV5_FORM2_AFFINITY)) {
|
|
|
|
return FORM2_NUMA_ASSOC_SIZE;
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:43 +03:00
|
|
|
return FORM1_NUMA_ASSOC_SIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieves vcpu_assoc_size of the current NUMA affinity.
|
|
|
|
*
|
|
|
|
* vcpu_assoc_size is the size of ibm,associativity array
|
|
|
|
* for CPUs, which has an extra element (vcpu_id) in the end.
|
|
|
|
*/
|
|
|
|
static int get_vcpu_assoc_size(SpaprMachineState *spapr)
|
|
|
|
{
|
|
|
|
return get_numa_assoc_size(spapr) + 1;
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:44 +03:00
|
|
|
/*
|
|
|
|
* Retrieves the ibm,associativity array of NUMA node 'node_id'
|
|
|
|
* for the current NUMA affinity.
|
|
|
|
*/
|
|
|
|
static const uint32_t *get_associativity(SpaprMachineState *spapr, int node_id)
|
|
|
|
{
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
if (spapr_ovec_test(spapr->ov5_cas, OV5_FORM2_AFFINITY)) {
|
|
|
|
return spapr->FORM2_assoc_array[node_id];
|
|
|
|
}
|
2021-09-20 20:49:44 +03:00
|
|
|
return spapr->FORM1_assoc_array[node_id];
|
|
|
|
}
|
|
|
|
|
2021-11-10 15:39:21 +03:00
|
|
|
/*
|
|
|
|
* Wrapper that returns node distance from ms->numa_state->nodes
|
|
|
|
* after handling edge cases where the distance might be absent.
|
|
|
|
*/
|
|
|
|
static int get_numa_distance(MachineState *ms, int src, int dst)
|
|
|
|
{
|
|
|
|
NodeInfo *numa_info = ms->numa_state->nodes;
|
|
|
|
int ret = numa_info[src].distance[dst];
|
|
|
|
|
|
|
|
if (ret != 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In case QEMU adds a default NUMA single node when the user
|
|
|
|
* did not add any, or where the user did not supply distances,
|
|
|
|
* the distance will be absent (zero). Return local/remote
|
|
|
|
* distance in this case.
|
|
|
|
*/
|
|
|
|
if (src == dst) {
|
|
|
|
return NUMA_DISTANCE_MIN;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NUMA_DISTANCE_DEFAULT;
|
|
|
|
}
|
|
|
|
|
2020-10-07 20:28:46 +03:00
|
|
|
static bool spapr_numa_is_symmetrical(MachineState *ms)
|
|
|
|
{
|
|
|
|
int nb_numa_nodes = ms->numa_state->num_nodes;
|
2021-11-10 15:39:21 +03:00
|
|
|
int src, dst;
|
2020-10-07 20:28:46 +03:00
|
|
|
|
|
|
|
for (src = 0; src < nb_numa_nodes; src++) {
|
|
|
|
for (dst = src; dst < nb_numa_nodes; dst++) {
|
2021-11-10 15:39:21 +03:00
|
|
|
if (get_numa_distance(ms, src, dst) !=
|
|
|
|
get_numa_distance(ms, dst, src)) {
|
2020-10-07 20:28:46 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
spapr_numa: consider user input when defining associativity
A new function called spapr_numa_define_associativity_domains()
is created to calculate the associativity domains and change
the associativity arrays considering user input. This is how
the associativity domain between two NUMA nodes A and B is
calculated:
- get the distance D between them
- get the correspondent NUMA level 'n_level' for D. This is done
via a helper called spapr_numa_get_numa_level()
- all associativity arrays were initialized with their own
numa_ids, and we're calculating the distance in node_id ascending
order, starting from node id 0 (the first node retrieved by
numa_state). This will have a cascade effect in the algorithm because
the associativity domains that node 0 defines will be carried over to
other nodes, and node 1 associativities will be carried over after
taking node 0 associativities into account, and so on. This
happens because we'll assign assoc_src as the associativity domain
of dst as well, for all NUMA levels beyond and including n_level.
The PPC kernel expects the associativity domains of the first node
(node id 0) to be always 0 [1], and this algorithm will grant that
by default.
Ultimately, all of this results in a best effort approximation for
the actual NUMA distances the user input in the command line. Given
the nature of how PAPR itself interprets NUMA distances versus the
expectations risen by how ACPI SLIT works, there might be better
algorithms but, in the end, it'll also result in another way to
approximate what the user really wanted.
To keep this commit message no longer than it already is, the next
patch will update the existing documentation in ppc-spapr-numa.rst
with more in depth details and design considerations/drawbacks.
[1] https://lore.kernel.org/linuxppc-dev/5e8fbea3-8faf-0951-172a-b41a2138fbcf@gmail.com/
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201007172849.302240-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-07 20:28:48 +03:00
|
|
|
/*
|
|
|
|
* This function will translate the user distances into
|
|
|
|
* what the kernel understand as possible values: 10
|
|
|
|
* (local distance), 20, 40, 80 and 160, and return the equivalent
|
|
|
|
* NUMA level for each. Current heuristic is:
|
|
|
|
* - local distance (10) returns numa_level = 0x4, meaning there is
|
|
|
|
* no rounding for local distance
|
|
|
|
* - distances between 11 and 30 inclusive -> rounded to 20,
|
|
|
|
* numa_level = 0x3
|
|
|
|
* - distances between 31 and 60 inclusive -> rounded to 40,
|
|
|
|
* numa_level = 0x2
|
|
|
|
* - distances between 61 and 120 inclusive -> rounded to 80,
|
|
|
|
* numa_level = 0x1
|
|
|
|
* - everything above 120 returns numa_level = 0 to indicate that
|
|
|
|
* there is no match. This will be calculated as disntace = 160
|
|
|
|
* by the kernel (as of v5.9)
|
|
|
|
*/
|
|
|
|
static uint8_t spapr_numa_get_numa_level(uint8_t distance)
|
|
|
|
{
|
|
|
|
if (distance == 10) {
|
|
|
|
return 0x4;
|
|
|
|
} else if (distance > 11 && distance <= 30) {
|
|
|
|
return 0x3;
|
|
|
|
} else if (distance > 31 && distance <= 60) {
|
|
|
|
return 0x2;
|
|
|
|
} else if (distance > 61 && distance <= 120) {
|
|
|
|
return 0x1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:41 +03:00
|
|
|
static void spapr_numa_define_FORM1_domains(SpaprMachineState *spapr)
|
spapr_numa: consider user input when defining associativity
A new function called spapr_numa_define_associativity_domains()
is created to calculate the associativity domains and change
the associativity arrays considering user input. This is how
the associativity domain between two NUMA nodes A and B is
calculated:
- get the distance D between them
- get the correspondent NUMA level 'n_level' for D. This is done
via a helper called spapr_numa_get_numa_level()
- all associativity arrays were initialized with their own
numa_ids, and we're calculating the distance in node_id ascending
order, starting from node id 0 (the first node retrieved by
numa_state). This will have a cascade effect in the algorithm because
the associativity domains that node 0 defines will be carried over to
other nodes, and node 1 associativities will be carried over after
taking node 0 associativities into account, and so on. This
happens because we'll assign assoc_src as the associativity domain
of dst as well, for all NUMA levels beyond and including n_level.
The PPC kernel expects the associativity domains of the first node
(node id 0) to be always 0 [1], and this algorithm will grant that
by default.
Ultimately, all of this results in a best effort approximation for
the actual NUMA distances the user input in the command line. Given
the nature of how PAPR itself interprets NUMA distances versus the
expectations risen by how ACPI SLIT works, there might be better
algorithms but, in the end, it'll also result in another way to
approximate what the user really wanted.
To keep this commit message no longer than it already is, the next
patch will update the existing documentation in ppc-spapr-numa.rst
with more in depth details and design considerations/drawbacks.
[1] https://lore.kernel.org/linuxppc-dev/5e8fbea3-8faf-0951-172a-b41a2138fbcf@gmail.com/
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201007172849.302240-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-07 20:28:48 +03:00
|
|
|
{
|
|
|
|
MachineState *ms = MACHINE(spapr);
|
|
|
|
int nb_numa_nodes = ms->numa_state->num_nodes;
|
2021-09-20 20:49:42 +03:00
|
|
|
int src, dst, i, j;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fill all associativity domains of non-zero NUMA nodes with
|
|
|
|
* node_id. This is required because the default value (0) is
|
|
|
|
* considered a match with associativity domains of node 0.
|
|
|
|
*/
|
|
|
|
for (i = 1; i < nb_numa_nodes; i++) {
|
2021-09-20 20:49:43 +03:00
|
|
|
for (j = 1; j < FORM1_DIST_REF_POINTS; j++) {
|
2021-09-20 20:49:44 +03:00
|
|
|
spapr->FORM1_assoc_array[i][j] = cpu_to_be32(i);
|
2021-09-20 20:49:42 +03:00
|
|
|
}
|
|
|
|
}
|
spapr_numa: consider user input when defining associativity
A new function called spapr_numa_define_associativity_domains()
is created to calculate the associativity domains and change
the associativity arrays considering user input. This is how
the associativity domain between two NUMA nodes A and B is
calculated:
- get the distance D between them
- get the correspondent NUMA level 'n_level' for D. This is done
via a helper called spapr_numa_get_numa_level()
- all associativity arrays were initialized with their own
numa_ids, and we're calculating the distance in node_id ascending
order, starting from node id 0 (the first node retrieved by
numa_state). This will have a cascade effect in the algorithm because
the associativity domains that node 0 defines will be carried over to
other nodes, and node 1 associativities will be carried over after
taking node 0 associativities into account, and so on. This
happens because we'll assign assoc_src as the associativity domain
of dst as well, for all NUMA levels beyond and including n_level.
The PPC kernel expects the associativity domains of the first node
(node id 0) to be always 0 [1], and this algorithm will grant that
by default.
Ultimately, all of this results in a best effort approximation for
the actual NUMA distances the user input in the command line. Given
the nature of how PAPR itself interprets NUMA distances versus the
expectations risen by how ACPI SLIT works, there might be better
algorithms but, in the end, it'll also result in another way to
approximate what the user really wanted.
To keep this commit message no longer than it already is, the next
patch will update the existing documentation in ppc-spapr-numa.rst
with more in depth details and design considerations/drawbacks.
[1] https://lore.kernel.org/linuxppc-dev/5e8fbea3-8faf-0951-172a-b41a2138fbcf@gmail.com/
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201007172849.302240-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-07 20:28:48 +03:00
|
|
|
|
|
|
|
for (src = 0; src < nb_numa_nodes; src++) {
|
|
|
|
for (dst = src; dst < nb_numa_nodes; dst++) {
|
|
|
|
/*
|
|
|
|
* This is how the associativity domain between A and B
|
|
|
|
* is calculated:
|
|
|
|
*
|
|
|
|
* - get the distance D between them
|
|
|
|
* - get the correspondent NUMA level 'n_level' for D
|
|
|
|
* - all associativity arrays were initialized with their own
|
|
|
|
* numa_ids, and we're calculating the distance in node_id
|
|
|
|
* ascending order, starting from node id 0 (the first node
|
|
|
|
* retrieved by numa_state). This will have a cascade effect in
|
|
|
|
* the algorithm because the associativity domains that node 0
|
|
|
|
* defines will be carried over to other nodes, and node 1
|
|
|
|
* associativities will be carried over after taking node 0
|
|
|
|
* associativities into account, and so on. This happens because
|
|
|
|
* we'll assign assoc_src as the associativity domain of dst
|
|
|
|
* as well, for all NUMA levels beyond and including n_level.
|
|
|
|
*
|
|
|
|
* The PPC kernel expects the associativity domains of node 0 to
|
|
|
|
* be always 0, and this algorithm will grant that by default.
|
|
|
|
*/
|
2021-11-10 15:39:21 +03:00
|
|
|
uint8_t distance = get_numa_distance(ms, src, dst);
|
spapr_numa: consider user input when defining associativity
A new function called spapr_numa_define_associativity_domains()
is created to calculate the associativity domains and change
the associativity arrays considering user input. This is how
the associativity domain between two NUMA nodes A and B is
calculated:
- get the distance D between them
- get the correspondent NUMA level 'n_level' for D. This is done
via a helper called spapr_numa_get_numa_level()
- all associativity arrays were initialized with their own
numa_ids, and we're calculating the distance in node_id ascending
order, starting from node id 0 (the first node retrieved by
numa_state). This will have a cascade effect in the algorithm because
the associativity domains that node 0 defines will be carried over to
other nodes, and node 1 associativities will be carried over after
taking node 0 associativities into account, and so on. This
happens because we'll assign assoc_src as the associativity domain
of dst as well, for all NUMA levels beyond and including n_level.
The PPC kernel expects the associativity domains of the first node
(node id 0) to be always 0 [1], and this algorithm will grant that
by default.
Ultimately, all of this results in a best effort approximation for
the actual NUMA distances the user input in the command line. Given
the nature of how PAPR itself interprets NUMA distances versus the
expectations risen by how ACPI SLIT works, there might be better
algorithms but, in the end, it'll also result in another way to
approximate what the user really wanted.
To keep this commit message no longer than it already is, the next
patch will update the existing documentation in ppc-spapr-numa.rst
with more in depth details and design considerations/drawbacks.
[1] https://lore.kernel.org/linuxppc-dev/5e8fbea3-8faf-0951-172a-b41a2138fbcf@gmail.com/
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201007172849.302240-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-07 20:28:48 +03:00
|
|
|
uint8_t n_level = spapr_numa_get_numa_level(distance);
|
|
|
|
uint32_t assoc_src;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* n_level = 0 means that the distance is greater than our last
|
|
|
|
* rounded value (120). In this case there is no NUMA level match
|
|
|
|
* between src and dst and we can skip the remaining of the loop.
|
|
|
|
*
|
|
|
|
* The Linux kernel will assume that the distance between src and
|
|
|
|
* dst, in this case of no match, is 10 (local distance) doubled
|
2021-09-20 20:49:43 +03:00
|
|
|
* for each NUMA it didn't match. We have FORM1_DIST_REF_POINTS
|
spapr_numa: consider user input when defining associativity
A new function called spapr_numa_define_associativity_domains()
is created to calculate the associativity domains and change
the associativity arrays considering user input. This is how
the associativity domain between two NUMA nodes A and B is
calculated:
- get the distance D between them
- get the correspondent NUMA level 'n_level' for D. This is done
via a helper called spapr_numa_get_numa_level()
- all associativity arrays were initialized with their own
numa_ids, and we're calculating the distance in node_id ascending
order, starting from node id 0 (the first node retrieved by
numa_state). This will have a cascade effect in the algorithm because
the associativity domains that node 0 defines will be carried over to
other nodes, and node 1 associativities will be carried over after
taking node 0 associativities into account, and so on. This
happens because we'll assign assoc_src as the associativity domain
of dst as well, for all NUMA levels beyond and including n_level.
The PPC kernel expects the associativity domains of the first node
(node id 0) to be always 0 [1], and this algorithm will grant that
by default.
Ultimately, all of this results in a best effort approximation for
the actual NUMA distances the user input in the command line. Given
the nature of how PAPR itself interprets NUMA distances versus the
expectations risen by how ACPI SLIT works, there might be better
algorithms but, in the end, it'll also result in another way to
approximate what the user really wanted.
To keep this commit message no longer than it already is, the next
patch will update the existing documentation in ppc-spapr-numa.rst
with more in depth details and design considerations/drawbacks.
[1] https://lore.kernel.org/linuxppc-dev/5e8fbea3-8faf-0951-172a-b41a2138fbcf@gmail.com/
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201007172849.302240-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-07 20:28:48 +03:00
|
|
|
* levels (4), so this gives us 10*2*2*2*2 = 160.
|
|
|
|
*
|
|
|
|
* This logic can be seen in the Linux kernel source code, as of
|
|
|
|
* v5.9, in arch/powerpc/mm/numa.c, function __node_distance().
|
|
|
|
*/
|
|
|
|
if (n_level == 0) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We must assign all assoc_src to dst, starting from n_level
|
|
|
|
* and going up to 0x1.
|
|
|
|
*/
|
|
|
|
for (i = n_level; i > 0; i--) {
|
2021-09-20 20:49:44 +03:00
|
|
|
assoc_src = spapr->FORM1_assoc_array[src][i];
|
|
|
|
spapr->FORM1_assoc_array[dst][i] = assoc_src;
|
spapr_numa: consider user input when defining associativity
A new function called spapr_numa_define_associativity_domains()
is created to calculate the associativity domains and change
the associativity arrays considering user input. This is how
the associativity domain between two NUMA nodes A and B is
calculated:
- get the distance D between them
- get the correspondent NUMA level 'n_level' for D. This is done
via a helper called spapr_numa_get_numa_level()
- all associativity arrays were initialized with their own
numa_ids, and we're calculating the distance in node_id ascending
order, starting from node id 0 (the first node retrieved by
numa_state). This will have a cascade effect in the algorithm because
the associativity domains that node 0 defines will be carried over to
other nodes, and node 1 associativities will be carried over after
taking node 0 associativities into account, and so on. This
happens because we'll assign assoc_src as the associativity domain
of dst as well, for all NUMA levels beyond and including n_level.
The PPC kernel expects the associativity domains of the first node
(node id 0) to be always 0 [1], and this algorithm will grant that
by default.
Ultimately, all of this results in a best effort approximation for
the actual NUMA distances the user input in the command line. Given
the nature of how PAPR itself interprets NUMA distances versus the
expectations risen by how ACPI SLIT works, there might be better
algorithms but, in the end, it'll also result in another way to
approximate what the user really wanted.
To keep this commit message no longer than it already is, the next
patch will update the existing documentation in ppc-spapr-numa.rst
with more in depth details and design considerations/drawbacks.
[1] https://lore.kernel.org/linuxppc-dev/5e8fbea3-8faf-0951-172a-b41a2138fbcf@gmail.com/
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201007172849.302240-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-07 20:28:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:45 +03:00
|
|
|
static void spapr_numa_FORM1_affinity_check(MachineState *machine)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check we don't have a memory-less/cpu-less NUMA node
|
|
|
|
* Firmware relies on the existing memory/cpu topology to provide the
|
|
|
|
* NUMA topology to the kernel.
|
|
|
|
* And the linux kernel needs to know the NUMA topology at start
|
|
|
|
* to be able to hotplug CPUs later.
|
|
|
|
*/
|
|
|
|
if (machine->numa_state->num_nodes) {
|
|
|
|
for (i = 0; i < machine->numa_state->num_nodes; ++i) {
|
|
|
|
/* check for memory-less node */
|
|
|
|
if (machine->numa_state->nodes[i].node_mem == 0) {
|
|
|
|
CPUState *cs;
|
|
|
|
int found = 0;
|
|
|
|
/* check for cpu-less node */
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
if (cpu->node_id == i) {
|
|
|
|
found = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* memory-less and cpu-less node */
|
|
|
|
if (!found) {
|
|
|
|
error_report(
|
|
|
|
"Memory-less/cpu-less nodes are not supported with FORM1 NUMA (node %d)", i);
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!spapr_numa_is_symmetrical(machine)) {
|
|
|
|
error_report(
|
|
|
|
"Asymmetrical NUMA topologies aren't supported in the pSeries machine using FORM1 NUMA");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:41 +03:00
|
|
|
/*
|
|
|
|
* Set NUMA machine state data based on FORM1 affinity semantics.
|
|
|
|
*/
|
|
|
|
static void spapr_numa_FORM1_affinity_init(SpaprMachineState *spapr,
|
|
|
|
MachineState *machine)
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
{
|
2020-09-04 01:06:36 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
int nb_numa_nodes = machine->numa_state->num_nodes;
|
2023-09-18 12:17:17 +03:00
|
|
|
int i, j;
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For all associativity arrays: first position is the size,
|
2021-09-20 20:49:43 +03:00
|
|
|
* position FORM1_DIST_REF_POINTS is always the numa_id,
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
* represented by the index 'i'.
|
|
|
|
*
|
|
|
|
* This will break on sparse NUMA setups, when/if QEMU starts
|
|
|
|
* to support it, because there will be no more guarantee that
|
|
|
|
* 'i' will be a valid node_id set by the user.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nb_numa_nodes; i++) {
|
2021-09-20 20:49:44 +03:00
|
|
|
spapr->FORM1_assoc_array[i][0] = cpu_to_be32(FORM1_DIST_REF_POINTS);
|
|
|
|
spapr->FORM1_assoc_array[i][FORM1_DIST_REF_POINTS] = cpu_to_be32(i);
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
}
|
2020-09-04 01:06:36 +03:00
|
|
|
|
2023-09-18 12:17:17 +03:00
|
|
|
for (i = nb_numa_nodes; i < nb_numa_nodes; i++) {
|
2021-09-20 20:49:44 +03:00
|
|
|
spapr->FORM1_assoc_array[i][0] = cpu_to_be32(FORM1_DIST_REF_POINTS);
|
2020-09-04 01:06:36 +03:00
|
|
|
|
2021-09-20 20:49:43 +03:00
|
|
|
for (j = 1; j < FORM1_DIST_REF_POINTS; j++) {
|
2020-09-04 01:06:36 +03:00
|
|
|
uint32_t gpu_assoc = smc->pre_5_1_assoc_refpoints ?
|
|
|
|
SPAPR_GPU_NUMA_ID : cpu_to_be32(i);
|
2021-09-20 20:49:44 +03:00
|
|
|
spapr->FORM1_assoc_array[i][j] = gpu_assoc;
|
2020-09-04 01:06:36 +03:00
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:44 +03:00
|
|
|
spapr->FORM1_assoc_array[i][FORM1_DIST_REF_POINTS] = cpu_to_be32(i);
|
2020-09-04 01:06:36 +03:00
|
|
|
}
|
2020-10-07 20:28:46 +03:00
|
|
|
|
|
|
|
/*
|
2021-09-20 20:49:42 +03:00
|
|
|
* Guests pseries-5.1 and older uses zeroed associativity domains,
|
|
|
|
* i.e. no domain definition based on NUMA distance input.
|
|
|
|
*
|
|
|
|
* Same thing with guests that have only one NUMA node.
|
2020-10-07 20:28:46 +03:00
|
|
|
*/
|
2021-09-20 20:49:42 +03:00
|
|
|
if (smc->pre_5_2_numa_associativity ||
|
|
|
|
machine->numa_state->num_nodes <= 1) {
|
2020-10-07 20:28:46 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:41 +03:00
|
|
|
spapr_numa_define_FORM1_domains(spapr);
|
|
|
|
}
|
|
|
|
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
/*
|
|
|
|
* Init NUMA FORM2 machine state data
|
|
|
|
*/
|
|
|
|
static void spapr_numa_FORM2_affinity_init(SpaprMachineState *spapr)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For all resources but CPUs, FORM2 associativity arrays will
|
|
|
|
* be a size 2 array with the following format:
|
|
|
|
*
|
|
|
|
* ibm,associativity = {1, numa_id}
|
|
|
|
*
|
|
|
|
* CPUs will write an additional 'vcpu_id' on top of the arrays
|
|
|
|
* being initialized here. 'numa_id' is represented by the
|
|
|
|
* index 'i' of the loop.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < NUMA_NODES_MAX_NUM; i++) {
|
|
|
|
spapr->FORM2_assoc_array[i][0] = cpu_to_be32(1);
|
|
|
|
spapr->FORM2_assoc_array[i][1] = cpu_to_be32(i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:41 +03:00
|
|
|
void spapr_numa_associativity_init(SpaprMachineState *spapr,
|
|
|
|
MachineState *machine)
|
|
|
|
{
|
|
|
|
spapr_numa_FORM1_affinity_init(spapr, machine);
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
spapr_numa_FORM2_affinity_init(spapr);
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:45 +03:00
|
|
|
void spapr_numa_associativity_check(SpaprMachineState *spapr)
|
|
|
|
{
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
/*
|
|
|
|
* FORM2 does not have any restrictions we need to handle
|
|
|
|
* at CAS time, for now.
|
|
|
|
*/
|
|
|
|
if (spapr_ovec_test(spapr->ov5_cas, OV5_FORM2_AFFINITY)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:45 +03:00
|
|
|
spapr_numa_FORM1_affinity_check(MACHINE(spapr));
|
|
|
|
}
|
|
|
|
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
void spapr_numa_write_associativity_dt(SpaprMachineState *spapr, void *fdt,
|
|
|
|
int offset, int nodeid)
|
|
|
|
{
|
2021-09-20 20:49:44 +03:00
|
|
|
const uint32_t *associativity = get_associativity(spapr, nodeid);
|
|
|
|
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
_FDT((fdt_setprop(fdt, offset, "ibm,associativity",
|
2021-09-20 20:49:44 +03:00
|
|
|
associativity,
|
2021-09-20 20:49:43 +03:00
|
|
|
get_numa_assoc_size(spapr) * sizeof(uint32_t))));
|
2020-09-04 01:06:34 +03:00
|
|
|
}
|
|
|
|
|
2020-09-04 20:24:21 +03:00
|
|
|
static uint32_t *spapr_numa_get_vcpu_assoc(SpaprMachineState *spapr,
|
|
|
|
PowerPCCPU *cpu)
|
2020-09-04 01:06:34 +03:00
|
|
|
{
|
2021-09-20 20:49:44 +03:00
|
|
|
const uint32_t *associativity = get_associativity(spapr, cpu->node_id);
|
2021-09-20 20:49:43 +03:00
|
|
|
int max_distance_ref_points = get_max_dist_ref_points(spapr);
|
|
|
|
int vcpu_assoc_size = get_vcpu_assoc_size(spapr);
|
|
|
|
uint32_t *vcpu_assoc = g_new(uint32_t, vcpu_assoc_size);
|
2020-09-04 01:06:34 +03:00
|
|
|
int index = spapr_get_vcpu_id(cpu);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* VCPUs have an extra 'cpu_id' value in ibm,associativity
|
|
|
|
* compared to other resources. Increment the size at index
|
2020-09-04 20:24:21 +03:00
|
|
|
* 0, put cpu_id last, then copy the remaining associativity
|
|
|
|
* domains.
|
2020-09-04 01:06:34 +03:00
|
|
|
*/
|
2021-09-20 20:49:43 +03:00
|
|
|
vcpu_assoc[0] = cpu_to_be32(max_distance_ref_points + 1);
|
|
|
|
vcpu_assoc[vcpu_assoc_size - 1] = cpu_to_be32(index);
|
2021-09-20 20:49:44 +03:00
|
|
|
memcpy(vcpu_assoc + 1, associativity + 1,
|
2021-09-20 20:49:43 +03:00
|
|
|
(vcpu_assoc_size - 2) * sizeof(uint32_t));
|
2020-09-04 01:06:34 +03:00
|
|
|
|
2020-09-04 20:24:21 +03:00
|
|
|
return vcpu_assoc;
|
|
|
|
}
|
|
|
|
|
|
|
|
int spapr_numa_fixup_cpu_dt(SpaprMachineState *spapr, void *fdt,
|
|
|
|
int offset, PowerPCCPU *cpu)
|
|
|
|
{
|
|
|
|
g_autofree uint32_t *vcpu_assoc = NULL;
|
2021-09-20 20:49:43 +03:00
|
|
|
int vcpu_assoc_size = get_vcpu_assoc_size(spapr);
|
2020-09-04 01:06:34 +03:00
|
|
|
|
2020-09-04 20:24:21 +03:00
|
|
|
vcpu_assoc = spapr_numa_get_vcpu_assoc(spapr, cpu);
|
2020-09-04 01:06:34 +03:00
|
|
|
|
|
|
|
/* Advertise NUMA via ibm,associativity */
|
2020-09-04 20:24:21 +03:00
|
|
|
return fdt_setprop(fdt, offset, "ibm,associativity", vcpu_assoc,
|
2021-09-20 20:49:43 +03:00
|
|
|
vcpu_assoc_size * sizeof(uint32_t));
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
}
|
|
|
|
|
2020-09-04 01:06:35 +03:00
|
|
|
|
|
|
|
int spapr_numa_write_assoc_lookup_arrays(SpaprMachineState *spapr, void *fdt,
|
|
|
|
int offset)
|
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
2021-09-20 20:49:43 +03:00
|
|
|
int max_distance_ref_points = get_max_dist_ref_points(spapr);
|
2020-09-04 01:06:35 +03:00
|
|
|
int nb_numa_nodes = machine->numa_state->num_nodes;
|
|
|
|
int nr_nodes = nb_numa_nodes ? nb_numa_nodes : 1;
|
2022-03-02 08:51:40 +03:00
|
|
|
g_autofree uint32_t *int_buf = NULL;
|
|
|
|
uint32_t *cur_index;
|
|
|
|
int i;
|
2020-09-04 01:06:35 +03:00
|
|
|
|
|
|
|
/* ibm,associativity-lookup-arrays */
|
2022-03-15 17:41:56 +03:00
|
|
|
int_buf = g_new0(uint32_t, nr_nodes * max_distance_ref_points + 2);
|
2022-03-02 08:51:40 +03:00
|
|
|
cur_index = int_buf;
|
2020-09-04 01:06:35 +03:00
|
|
|
int_buf[0] = cpu_to_be32(nr_nodes);
|
|
|
|
/* Number of entries per associativity list */
|
2021-09-20 20:49:43 +03:00
|
|
|
int_buf[1] = cpu_to_be32(max_distance_ref_points);
|
2020-09-04 01:06:35 +03:00
|
|
|
cur_index += 2;
|
|
|
|
for (i = 0; i < nr_nodes; i++) {
|
|
|
|
/*
|
2021-09-20 20:49:44 +03:00
|
|
|
* For the lookup-array we use the ibm,associativity array of the
|
|
|
|
* current NUMA affinity, without the first element (size).
|
2020-09-04 01:06:35 +03:00
|
|
|
*/
|
2021-09-20 20:49:44 +03:00
|
|
|
const uint32_t *associativity = get_associativity(spapr, i);
|
2020-09-04 01:06:35 +03:00
|
|
|
memcpy(cur_index, ++associativity,
|
2021-09-20 20:49:43 +03:00
|
|
|
sizeof(uint32_t) * max_distance_ref_points);
|
|
|
|
cur_index += max_distance_ref_points;
|
2020-09-04 01:06:35 +03:00
|
|
|
}
|
|
|
|
|
2022-03-02 08:51:40 +03:00
|
|
|
return fdt_setprop(fdt, offset, "ibm,associativity-lookup-arrays",
|
|
|
|
int_buf, (cur_index - int_buf) * sizeof(uint32_t));
|
2020-09-04 01:06:35 +03:00
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:41 +03:00
|
|
|
static void spapr_numa_FORM1_write_rtas_dt(SpaprMachineState *spapr,
|
|
|
|
void *fdt, int rtas)
|
2020-09-01 15:56:39 +03:00
|
|
|
{
|
2020-10-07 20:28:47 +03:00
|
|
|
MachineState *ms = MACHINE(spapr);
|
2020-09-01 15:56:39 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
|
|
|
uint32_t refpoints[] = {
|
|
|
|
cpu_to_be32(0x4),
|
2020-10-07 20:28:47 +03:00
|
|
|
cpu_to_be32(0x3),
|
2020-09-01 15:56:39 +03:00
|
|
|
cpu_to_be32(0x2),
|
2020-10-07 20:28:47 +03:00
|
|
|
cpu_to_be32(0x1),
|
2020-09-01 15:56:39 +03:00
|
|
|
};
|
|
|
|
uint32_t nr_refpoints = ARRAY_SIZE(refpoints);
|
2023-09-18 12:17:17 +03:00
|
|
|
uint32_t maxdomain = ms->numa_state->num_nodes;
|
2020-09-01 15:56:39 +03:00
|
|
|
uint32_t maxdomains[] = {
|
|
|
|
cpu_to_be32(4),
|
2020-10-07 20:28:47 +03:00
|
|
|
cpu_to_be32(maxdomain),
|
|
|
|
cpu_to_be32(maxdomain),
|
|
|
|
cpu_to_be32(maxdomain),
|
|
|
|
cpu_to_be32(maxdomain)
|
2020-09-01 15:56:39 +03:00
|
|
|
};
|
|
|
|
|
2021-09-20 20:49:42 +03:00
|
|
|
if (smc->pre_5_2_numa_associativity ||
|
|
|
|
ms->numa_state->num_nodes <= 1) {
|
2020-10-07 20:28:47 +03:00
|
|
|
uint32_t legacy_refpoints[] = {
|
|
|
|
cpu_to_be32(0x4),
|
|
|
|
cpu_to_be32(0x4),
|
|
|
|
cpu_to_be32(0x2),
|
|
|
|
};
|
|
|
|
uint32_t legacy_maxdomains[] = {
|
|
|
|
cpu_to_be32(4),
|
2023-09-18 12:17:17 +03:00
|
|
|
cpu_to_be32(0),
|
|
|
|
cpu_to_be32(0),
|
|
|
|
cpu_to_be32(0),
|
|
|
|
cpu_to_be32(maxdomain ? maxdomain : 1),
|
2020-10-07 20:28:47 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
G_STATIC_ASSERT(sizeof(legacy_refpoints) <= sizeof(refpoints));
|
|
|
|
G_STATIC_ASSERT(sizeof(legacy_maxdomains) <= sizeof(maxdomains));
|
|
|
|
|
|
|
|
nr_refpoints = 3;
|
|
|
|
|
|
|
|
memcpy(refpoints, legacy_refpoints, sizeof(legacy_refpoints));
|
|
|
|
memcpy(maxdomains, legacy_maxdomains, sizeof(legacy_maxdomains));
|
|
|
|
|
|
|
|
/* pseries-5.0 and older reference-points array is {0x4, 0x4} */
|
|
|
|
if (smc->pre_5_1_assoc_refpoints) {
|
|
|
|
nr_refpoints = 2;
|
|
|
|
}
|
2020-09-01 15:56:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,associativity-reference-points",
|
|
|
|
refpoints, nr_refpoints * sizeof(refpoints[0])));
|
|
|
|
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,max-associativity-domains",
|
|
|
|
maxdomains, sizeof(maxdomains)));
|
|
|
|
}
|
2020-09-04 20:24:20 +03:00
|
|
|
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
static void spapr_numa_FORM2_write_rtas_tables(SpaprMachineState *spapr,
|
|
|
|
void *fdt, int rtas)
|
|
|
|
{
|
|
|
|
MachineState *ms = MACHINE(spapr);
|
|
|
|
int nb_numa_nodes = ms->numa_state->num_nodes;
|
|
|
|
int distance_table_entries = nb_numa_nodes * nb_numa_nodes;
|
|
|
|
g_autofree uint32_t *lookup_index_table = NULL;
|
2021-09-22 15:28:52 +03:00
|
|
|
g_autofree uint8_t *distance_table = NULL;
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
int src, dst, i, distance_table_size;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ibm,numa-lookup-index-table: array with length and a
|
|
|
|
* list of NUMA ids present in the guest.
|
|
|
|
*/
|
|
|
|
lookup_index_table = g_new0(uint32_t, nb_numa_nodes + 1);
|
|
|
|
lookup_index_table[0] = cpu_to_be32(nb_numa_nodes);
|
|
|
|
|
|
|
|
for (i = 0; i < nb_numa_nodes; i++) {
|
|
|
|
lookup_index_table[i + 1] = cpu_to_be32(i);
|
|
|
|
}
|
|
|
|
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,numa-lookup-index-table",
|
|
|
|
lookup_index_table,
|
|
|
|
(nb_numa_nodes + 1) * sizeof(uint32_t)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ibm,numa-distance-table: contains all node distances. First
|
|
|
|
* element is the size of the table as uint32, followed up
|
|
|
|
* by all the uint8 distances from the first NUMA node, then all
|
|
|
|
* distances from the second NUMA node and so on.
|
|
|
|
*
|
|
|
|
* ibm,numa-lookup-index-table is used by guest to navigate this
|
|
|
|
* array because NUMA ids can be sparse (node 0 is the first,
|
|
|
|
* node 8 is the second ...).
|
|
|
|
*/
|
2021-09-22 15:28:52 +03:00
|
|
|
distance_table_size = distance_table_entries * sizeof(uint8_t) +
|
|
|
|
sizeof(uint32_t);
|
|
|
|
distance_table = g_new0(uint8_t, distance_table_size);
|
|
|
|
stl_be_p(distance_table, distance_table_entries);
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
|
2021-09-22 15:28:52 +03:00
|
|
|
/* Skip the uint32_t array length at the start */
|
|
|
|
i = sizeof(uint32_t);
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
|
|
|
|
for (src = 0; src < nb_numa_nodes; src++) {
|
|
|
|
for (dst = 0; dst < nb_numa_nodes; dst++) {
|
2021-11-10 15:39:21 +03:00
|
|
|
distance_table[i++] = get_numa_distance(ms, src, dst);
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,numa-distance-table",
|
|
|
|
distance_table, distance_table_size));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This helper could be compressed in a single function with
|
|
|
|
* FORM1 logic since we're setting the same DT values, with the
|
|
|
|
* difference being a call to spapr_numa_FORM2_write_rtas_tables()
|
|
|
|
* in the end. The separation was made to avoid clogging FORM1 code
|
|
|
|
* which already has to deal with compat modes from previous
|
|
|
|
* QEMU machine types.
|
|
|
|
*/
|
|
|
|
static void spapr_numa_FORM2_write_rtas_dt(SpaprMachineState *spapr,
|
|
|
|
void *fdt, int rtas)
|
|
|
|
{
|
|
|
|
MachineState *ms = MACHINE(spapr);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In FORM2, ibm,associativity-reference-points will point to
|
|
|
|
* the element in the ibm,associativity array that contains the
|
|
|
|
* primary domain index (for FORM2, the first element).
|
|
|
|
*
|
|
|
|
* This value (in our case, the numa-id) is then used as an index
|
|
|
|
* to retrieve all other attributes of the node (distance,
|
|
|
|
* bandwidth, latency) via ibm,numa-lookup-index-table and other
|
|
|
|
* ibm,numa-*-table properties.
|
|
|
|
*/
|
|
|
|
uint32_t refpoints[] = { cpu_to_be32(1) };
|
|
|
|
|
2023-09-18 12:17:17 +03:00
|
|
|
uint32_t maxdomain = ms->numa_state->num_nodes;
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
uint32_t maxdomains[] = { cpu_to_be32(1), cpu_to_be32(maxdomain) };
|
|
|
|
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,associativity-reference-points",
|
|
|
|
refpoints, sizeof(refpoints)));
|
|
|
|
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,max-associativity-domains",
|
|
|
|
maxdomains, sizeof(maxdomains)));
|
|
|
|
|
|
|
|
spapr_numa_FORM2_write_rtas_tables(spapr, fdt, rtas);
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:41 +03:00
|
|
|
/*
|
|
|
|
* Helper that writes ibm,associativity-reference-points and
|
|
|
|
* max-associativity-domains in the RTAS pointed by @rtas
|
|
|
|
* in the DT @fdt.
|
|
|
|
*/
|
|
|
|
void spapr_numa_write_rtas_dt(SpaprMachineState *spapr, void *fdt, int rtas)
|
|
|
|
{
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
if (spapr_ovec_test(spapr->ov5_cas, OV5_FORM2_AFFINITY)) {
|
|
|
|
spapr_numa_FORM2_write_rtas_dt(spapr, fdt, rtas);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-09-20 20:49:41 +03:00
|
|
|
spapr_numa_FORM1_write_rtas_dt(spapr, fdt, rtas);
|
|
|
|
}
|
|
|
|
|
2020-09-04 20:24:20 +03:00
|
|
|
static target_ulong h_home_node_associativity(PowerPCCPU *cpu,
|
|
|
|
SpaprMachineState *spapr,
|
|
|
|
target_ulong opcode,
|
|
|
|
target_ulong *args)
|
|
|
|
{
|
2020-09-04 20:24:22 +03:00
|
|
|
g_autofree uint32_t *vcpu_assoc = NULL;
|
2020-09-04 20:24:20 +03:00
|
|
|
target_ulong flags = args[0];
|
|
|
|
target_ulong procno = args[1];
|
|
|
|
PowerPCCPU *tcpu;
|
2020-09-04 20:24:22 +03:00
|
|
|
int idx, assoc_idx;
|
2021-09-20 20:49:43 +03:00
|
|
|
int vcpu_assoc_size = get_vcpu_assoc_size(spapr);
|
2020-09-04 20:24:20 +03:00
|
|
|
|
|
|
|
/* only support procno from H_REGISTER_VPA */
|
|
|
|
if (flags != 0x1) {
|
|
|
|
return H_FUNCTION;
|
|
|
|
}
|
|
|
|
|
|
|
|
tcpu = spapr_find_cpu(procno);
|
|
|
|
if (tcpu == NULL) {
|
|
|
|
return H_P2;
|
|
|
|
}
|
|
|
|
|
2020-09-04 20:24:22 +03:00
|
|
|
/*
|
|
|
|
* Given that we want to be flexible with the sizes and indexes,
|
|
|
|
* we must consider that there is a hard limit of how many
|
|
|
|
* associativities domain we can fit in R4 up to R9, which would be
|
|
|
|
* 12 associativity domains for vcpus. Assert and bail if that's
|
|
|
|
* not the case.
|
|
|
|
*/
|
2021-09-20 20:49:43 +03:00
|
|
|
g_assert((vcpu_assoc_size - 1) <= 12);
|
2020-09-04 20:24:22 +03:00
|
|
|
|
|
|
|
vcpu_assoc = spapr_numa_get_vcpu_assoc(spapr, tcpu);
|
|
|
|
/* assoc_idx starts at 1 to skip associativity size */
|
|
|
|
assoc_idx = 1;
|
2020-09-04 20:24:20 +03:00
|
|
|
|
|
|
|
#define ASSOCIATIVITY(a, b) (((uint64_t)(a) << 32) | \
|
|
|
|
((uint64_t)(b) & 0xffffffff))
|
2020-09-04 20:24:22 +03:00
|
|
|
|
|
|
|
for (idx = 0; idx < 6; idx++) {
|
|
|
|
int32_t a, b;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* vcpu_assoc[] will contain the associativity domains for tcpu,
|
|
|
|
* including tcpu->node_id and procno, meaning that we don't
|
|
|
|
* need to use these variables here.
|
|
|
|
*
|
|
|
|
* We'll read 2 values at a time to fill up the ASSOCIATIVITY()
|
|
|
|
* macro. The ternary will fill the remaining registers with -1
|
|
|
|
* after we went through vcpu_assoc[].
|
|
|
|
*/
|
2021-09-20 20:49:43 +03:00
|
|
|
a = assoc_idx < vcpu_assoc_size ?
|
2020-09-04 20:24:22 +03:00
|
|
|
be32_to_cpu(vcpu_assoc[assoc_idx++]) : -1;
|
2021-09-20 20:49:43 +03:00
|
|
|
b = assoc_idx < vcpu_assoc_size ?
|
2020-09-04 20:24:22 +03:00
|
|
|
be32_to_cpu(vcpu_assoc[assoc_idx++]) : -1;
|
|
|
|
|
|
|
|
args[idx] = ASSOCIATIVITY(a, b);
|
2020-09-04 20:24:20 +03:00
|
|
|
}
|
|
|
|
#undef ASSOCIATIVITY
|
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_numa_register_types(void)
|
|
|
|
{
|
|
|
|
/* Virtual Processor Home Node */
|
|
|
|
spapr_register_hypercall(H_HOME_NODE_ASSOCIATIVITY,
|
|
|
|
h_home_node_associativity);
|
|
|
|
}
|
|
|
|
|
|
|
|
type_init(spapr_numa_register_types)
|