On Mon, 14 Jul 2025 11:57:19 -0400
"Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Mon, Jul 14, 2025 at 03:10:41PM +0100, Alireza Sanaee wrote:
> > On Mon, 14 Jul 2025 09:09:10 -0400
> > "Michael S. Tsirkin" <m...@redhat.com> wrote:
> >
> > > On Wed, Jun 04, 2025 at 12:52:32PM +0100, Alireza Sanaee wrote:
> > > > From: Yicong Yang <yangyic...@hisilicon.com>
> > > >
> > > > Currently we build the PPTT starting from the socket node and each
> > > > socket will be a separate tree. For a multi-socket system it'll
> > > > be hard for the OS to know the whole system is homogeneous or not
> > > > (actually we're in the current implementation) since no parent node
> > > > to telling the identical implementation informentation. Add a
> > > > root node for indicating this.
> > > >
> > > > Signed-off-by: Yicong Yang <yangyic...@hisilicon.com>
> > > > Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>
> > > > Signed-off-by: Alireza Sanaee <alireza.san...@huawei.com>
> > > > ---
> > > > hw/acpi/aml-build.c | 15 ++++++++++++++-
> > > > 1 file changed, 14 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> > > > index 560cee12a2..76a4157a18 100644
> > > > --- a/hw/acpi/aml-build.c
> > > > +++ b/hw/acpi/aml-build.c
> > > > @@ -2153,12 +2153,25 @@ void build_pptt(GArray *table_data,
> > > > BIOSLinker *linker, MachineState *ms, int64_t socket_id = -1,
> > > > cluster_id = -1, core_id = -1; uint32_t socket_offset = 0,
> > > > cluster_offset = 0, core_offset = 0; uint32_t pptt_start =
> > > > table_data->len;
> > > > + uint32_t root_offset;
> > > > int n;
> > > > AcpiTable table = { .sig = "PPTT", .rev = 2,
> > > > .oem_id = oem_id, .oem_table_id =
> > > > oem_table_id };
> > > > acpi_table_begin(&table, table_data);
> > > >
> > > > + /*
> > > > + * Build a root node for all the processor nodes. Otherwise
> > > > when
> > > > + * building a multi-socket system each socket tree is separated
> > > > + * and will be hard for the OS like Linux to know whether the
> > > > + * system is homogeneous.
> > > > + */
> > > > + root_offset = table_data->len - pptt_start;
> > > > + build_processor_hierarchy_node(table_data,
> > > > + (1 << 0) | /* Physical package */
> > > > + (1 << 4), /* Identical Implementation */
> > > > + 0, 0, NULL, 0);
> > > > +
> > > > /*
> > > > * This works with the assumption that cpus[n].props.*_id has
> > > > been
> > > > * sorted from top to down levels in
> > > > mc->possible_cpu_arch_ids(). @@ -2175,7 +2188,7 @@ void
> > > > build_pptt(GArray *table_data, BIOSLinker *linker, MachineState
> > > > *ms, build_processor_hierarchy_node(table_data, (1 << 0) | /*
> > > > Physical package */ (1 << 4), /* Identical Implementation */
> > > > - 0, socket_id, NULL, 0);
> > > > + root_offset, socket_id, NULL, 0);
> > > > }
> > > >
> > > > if (mc->smp_props.clusters_supported &&
> > > > mc->smp_props.has_clusters) {
> > >
> > >
> > > This function is also used by loongarch64, but you do not update the
> > > loongarch64 expected files:
> > > https://gitlab.com/mstredhat/qemu/-/jobs/10672661860
> >
> > Hi Michael,
> >
> > There are new tests you have brought in the
> > tree after mine.
> > https://gitlab.com/mstredhat/qemu/-/commit/9e4f80654cefd051f8f5c220d5447201b6cf1810
> >
> > I can try to fix this and resend with updated PPTT files for
> > loongarch64. WDYT?
>
> That commit is in master though, right?
Hi Michael,
Which master do you mean? As far as I can tell the above commit isn't
anywhere other than your gitlab and, in for failures that were
triggering there earlier today, it was later in the tree than this
series (so the problem didn't manifest in this series at all)
That had Ali and I confused for a while as we couldn't replicate.
Anyhow, someone had to do a rebase either way so not a problem.
Jonathan
> Sounds good, pls do.
>
> > >
> > > > --
> > > > 2.43.0
> > >
> > >
>
>
