spapr_numa.c: scrap 'legacy_numa' concept
commitafa3b3c9ee8ae2c7c25c93f2d6eebe09e962cd3a
authorDaniel Henrique Barboza <danielhb413@gmail.com>
Mon, 20 Sep 2021 17:49:42 +0000 (20 14:49 -0300)
committerDavid Gibson <david@gibson.dropbear.id.au>
Thu, 30 Sep 2021 02:26:06 +0000 (30 12:26 +1000)
tree7c651bb6c3a243f89ad38da21c976ecc3c2281d8
parentd98dbe2a2bec249847e789d0cb42eb5e7e93343d
spapr_numa.c: scrap 'legacy_numa' concept

When first introduced, 'legacy_numa' was a way to refer to guests that
either wouldn't be affected by associativity domain calculations, namely
the ones with only 1 NUMA node, and pre 5.2 guests that shouldn't be
affected by it because it would be an userspace change. Calling these
cases 'legacy_numa' was a convenient way to label these cases.

We're about to introduce a new NUMA affinity, FORM2, and this concept
of 'legacy_numa' is now a bit misleading because, although it is called
'legacy' it is in fact a FORM1 exclusive contraint.

This patch removes spapr_machine_using_legacy_numa() and open code the
conditions in each caller. While we're at it, move the chunk inside
spapr_numa_FORM1_affinity_init() that sets all numa_assoc_array domains
with 'node_id' to spapr_numa_define_FORM1_domains(). This chunk was
being executed if !pre_5_2_numa_associativity and num_nodes => 1, the
same conditions in which spapr_numa_define_FORM1_domains() is called
shortly after.

Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
hw/ppc/spapr_numa.c