From: David Gibson <david@gibson.dropbear.id.au>
To: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, groug@kaod.org
Subject: Re: [PATCH v4 2/5] spapr_numa.c: split FORM1 code into helpers
Date: Tue, 7 Sep 2021 10:30:08 +1000 [thread overview]
Message-ID: <YTaykCjgeonaGS2x@yekko> (raw)
In-Reply-To: <20210827092455.125411-3-danielhb413@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4814 bytes --]
On Fri, Aug 27, 2021 at 06:24:52AM -0300, Daniel Henrique Barboza wrote:
> The upcoming FORM2 NUMA affinity will support asymmetric NUMA topologies
> and doesn't need be concerned with all the legacy support for older
> pseries FORM1 guests.
>
> We're also not going to calculate associativity domains based on numa
> distance (via spapr_numa_define_associativity_domains) since the
> distances will be written directly into new DT properties.
>
> Let's split FORM1 code into its own functions to allow for easier
> insertion of FORM2 logic later on.
>
> Reviewed-by: Greg Kurz <groug@kaod.org>
> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> ---
> hw/ppc/spapr_numa.c | 61 +++++++++++++++++++++++++++++----------------
> 1 file changed, 39 insertions(+), 22 deletions(-)
>
> diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
> index 779f18b994..04a86f9b5b 100644
> --- a/hw/ppc/spapr_numa.c
> +++ b/hw/ppc/spapr_numa.c
> @@ -155,6 +155,32 @@ static void spapr_numa_define_associativity_domains(SpaprMachineState *spapr)
>
> }
>
> +/*
> + * Set NUMA machine state data based on FORM1 affinity semantics.
> + */
> +static void spapr_numa_FORM1_affinity_init(SpaprMachineState *spapr,
> + MachineState *machine)
> +{
> + bool using_legacy_numa = spapr_machine_using_legacy_numa(spapr);
> +
> + /*
> + * Legacy NUMA guests (pseries-5.1 and older, or guests with only
> + * 1 NUMA node) will not benefit from anything we're going to do
> + * after this point.
> + */
> + if (using_legacy_numa) {
> + return;
> + }
My only concern with this patch is that handling the
"using_legacy_numa" case might logically belong outside the FORM1
code. I mean, I'm pretty sure using_legacy_numa implies FORM1 in
practice, but conceptually it seems like a more fundamental question
than the DT encoding of the NUMA information.
> +
> + if (!spapr_numa_is_symmetrical(machine)) {
> + error_report("Asymmetrical NUMA topologies aren't supported "
> + "in the pSeries machine");
> + exit(EXIT_FAILURE);
> + }
> +
> + spapr_numa_define_associativity_domains(spapr);
> +}
> +
> void spapr_numa_associativity_init(SpaprMachineState *spapr,
> MachineState *machine)
> {
> @@ -210,22 +236,7 @@ void spapr_numa_associativity_init(SpaprMachineState *spapr,
> spapr->numa_assoc_array[i][MAX_DISTANCE_REF_POINTS] = cpu_to_be32(i);
> }
>
> - /*
> - * Legacy NUMA guests (pseries-5.1 and older, or guests with only
> - * 1 NUMA node) will not benefit from anything we're going to do
> - * after this point.
> - */
> - if (using_legacy_numa) {
> - return;
> - }
> -
> - if (!spapr_numa_is_symmetrical(machine)) {
> - error_report("Asymmetrical NUMA topologies aren't supported "
> - "in the pSeries machine");
> - exit(EXIT_FAILURE);
> - }
> -
> - spapr_numa_define_associativity_domains(spapr);
> + spapr_numa_FORM1_affinity_init(spapr, machine);
> }
>
> void spapr_numa_write_associativity_dt(SpaprMachineState *spapr, void *fdt,
> @@ -302,12 +313,8 @@ int spapr_numa_write_assoc_lookup_arrays(SpaprMachineState *spapr, void *fdt,
> return ret;
> }
>
> -/*
> - * 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)
> +static void spapr_numa_FORM1_write_rtas_dt(SpaprMachineState *spapr,
> + void *fdt, int rtas)
> {
> MachineState *ms = MACHINE(spapr);
> SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
> @@ -365,6 +372,16 @@ void spapr_numa_write_rtas_dt(SpaprMachineState *spapr, void *fdt, int rtas)
> maxdomains, sizeof(maxdomains)));
> }
>
> +/*
> + * 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_FORM1_write_rtas_dt(spapr, fdt, rtas);
> +}
> +
> static target_ulong h_home_node_associativity(PowerPCCPU *cpu,
> SpaprMachineState *spapr,
> target_ulong opcode,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-09-07 0:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-27 9:24 [PATCH v4 0/5] pSeries FORM2 affinity support Daniel Henrique Barboza
2021-08-27 9:24 ` [PATCH v4 1/5] hw, spapr: add 6.2 compat pseries machine Daniel Henrique Barboza
2021-08-30 7:34 ` Greg Kurz
2021-08-30 18:24 ` Daniel Henrique Barboza
2021-08-30 18:32 ` Peter Maydell
2021-08-31 2:01 ` wangyanan (Y)
2021-08-27 9:24 ` [PATCH v4 2/5] spapr_numa.c: split FORM1 code into helpers Daniel Henrique Barboza
2021-09-07 0:30 ` David Gibson [this message]
2021-09-07 0:50 ` Daniel Henrique Barboza
2021-09-07 1:12 ` David Gibson
2021-08-27 9:24 ` [PATCH v4 3/5] spapr_numa.c: base FORM2 NUMA affinity support Daniel Henrique Barboza
2021-08-31 13:40 ` Greg Kurz
2021-08-31 14:13 ` Daniel Henrique Barboza
2021-08-31 14:51 ` Greg Kurz
2021-08-27 9:24 ` [PATCH v4 4/5] spapr: simplify spapr_numa_associativity_init params Daniel Henrique Barboza
2021-08-27 9:24 ` [PATCH v4 5/5] spapr: move memory/cpu less check to spapr_numa_FORM1_affinity_init() Daniel Henrique Barboza
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YTaykCjgeonaGS2x@yekko \
--to=david@gibson.dropbear.id.au \
--cc=danielhb413@gmail.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.