On Mon, Jul 14, 2025 at 05:06:05PM +0100, Alireza Sanaee wrote:
> 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?
> > Sounds good, pls do.
> 
> I do NOT think it is on the master. It is on v11-14-07-2025
> 
> I am trying to work it out on the most recent branch now.

Donnu, I thought I checked but you are right.
If you can help post updated tables (can be a patch on top,
I will squash) would be great.

> > 
> > > >   
> > > > > -- 
> > > > > 2.43.0    
> > > > 
> > > >   
> > 
> > 


Reply via email to