All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: aneesh.kumar@linux.ibm.com, qemu-ppc@nongnu.org,
	qemu-devel@nongnu.org, groug@kaod.org
Subject: Re: [RFC PATCH 3/8] spapr_numa.c: wait for CAS before writing rtas DT
Date: Tue, 15 Jun 2021 14:02:04 +1000	[thread overview]
Message-ID: <YMgmPDrr7oJFGME1@yekko> (raw)
In-Reply-To: <20210615013309.2833323-4-danielhb413@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

On Mon, Jun 14, 2021 at 10:33:04PM -0300, Daniel Henrique Barboza wrote:
> spapr_numa_write_rtas_dt() is called from spapr_dt_rtas(), which in
> turned is called by spapr_build_fdt(). spapr_build_fdt() is called in
> two places: spapr_machine_reset() and do_client_architecture_support().
> When called in machine_reset() we're writing RTAS nodes with NUMA
> artifacts without going through CAS first.
> 
> This is not an issue because we always write the same thing in DT, since
> we support just FORM1 NUMA affinity. With the upcoming FORM2 support,
> we're now reliant on guest choice to decide what to write.
> 
> Instead of taking a guess (e.g. default to FORM1, switch to FORM2 if
> guest chooses it), postpone the writing of
> ibm,associativity-reference-points and ibm,max-associativity-domains
> until we're sure what was negotiated with the guest.
> 
> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

I think it makes sense to fold this in with 1/8 moving the calculation
itself until after CAS.

This does make a (theoretical) functional change - it means that NUMA
information is not available before CAS, which it was before.  I think
that's very unlikely to break anything, but I wonder if we should make
it dependent on the machine version just to be safe.

> ---
>  hw/ppc/spapr_numa.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
> index 04a86f9b5b..e1a7f80076 100644
> --- a/hw/ppc/spapr_numa.c
> +++ b/hw/ppc/spapr_numa.c
> @@ -379,6 +379,10 @@ static void spapr_numa_FORM1_write_rtas_dt(SpaprMachineState *spapr,
>   */
>  void spapr_numa_write_rtas_dt(SpaprMachineState *spapr, void *fdt, int rtas)
>  {
> +    if (spapr_ovec_empty(spapr->ov5_cas)) {
> +        return;
> +    }
> +
>      spapr_numa_FORM1_write_rtas_dt(spapr, fdt, rtas);
>  }
>  

-- 
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 --]

  reply	other threads:[~2021-06-15  5:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15  1:33 [RFC PATCH 0/8] pSeries base FORM2 NUMA affinity support Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 1/8] spapr: move NUMA data init to do_client_architecture_support() Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 2/8] spapr_numa.c: split FORM1 code into helpers Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 3/8] spapr_numa.c: wait for CAS before writing rtas DT Daniel Henrique Barboza
2021-06-15  4:02   ` David Gibson [this message]
2021-06-15 20:26     ` Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 4/8] spapr_numa.c: base FORM2 NUMA affinity support Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 5/8] spapr: simplify spapr_numa_associativity_init params Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 6/8] nvdimm: add PPC64 'device-node' property Daniel Henrique Barboza
2021-06-15  9:33   ` Aneesh Kumar K.V
2021-06-15 20:13     ` Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 7/8] spapr_numa, spapar_nvdimm: write secondary NUMA domain for nvdimms Daniel Henrique Barboza
2021-06-15  1:33 ` [RFC PATCH 8/8] 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=YMgmPDrr7oJFGME1@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=aneesh.kumar@linux.ibm.com \
    --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.