From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: David Gibson <david@gibson.dropbear.id.au>
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 17:26:29 -0300 [thread overview]
Message-ID: <65a744dc-3edd-a0e8-4e32-dab7ad1d64d5@gmail.com> (raw)
In-Reply-To: <YMgmPDrr7oJFGME1@yekko>
On 6/15/21 1:02 AM, David Gibson wrote:
> 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.
Ok.
>
> 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.
I don't mind making it dependent on the default machine. I'll wrap this
CAS change (and as result, all FORM2 support) to be available only for
the default machine type.
Thanks,
Daniel
>
>> ---
>> 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);
>> }
>>
>
next prev parent reply other threads:[~2021-06-15 20:27 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
2021-06-15 20:26 ` Daniel Henrique Barboza [this message]
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=65a744dc-3edd-a0e8-4e32-dab7ad1d64d5@gmail.com \
--to=danielhb413@gmail.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=david@gibson.dropbear.id.au \
--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.