Re: [PATCH] i386/cpu: Introduce enable_cpuid_0x1f to force exposing CPUID 0x1f

[Zhao Liu <zhao1.liu@intel.com>]

On Thu, Aug 08, 2024 at 09:59:07PM +0800, Xiaoyao Li wrote:
> Date: Thu, 8 Aug 2024 21:59:07 +0800
> From: Xiaoyao Li <xiaoyao.li@intel.com>
> Subject: Re: [PATCH] i386/cpu: Introduce enable_cpuid_0x1f to force
>  exposing CPUID 0x1f
> 
> On 8/8/2024 6:09 PM, Zhao Liu wrote:
> > Hi Xiaoyao,
> > 
> > Patch is generally fine for me. Just a few nits:
> > 
> > On Fri, Aug 02, 2024 at 03:24:26AM -0400, Xiaoyao Li wrote:
> > > diff --git a/include/hw/i386/topology.h b/include/hw/i386/topology.h
> > > index dff49fce1154..b63bce2f4c82 100644
> > > --- a/include/hw/i386/topology.h
> > > +++ b/include/hw/i386/topology.h
> > > @@ -207,13 +207,4 @@ static inline apic_id_t x86_apicid_from_cpu_idx(X86CPUTopoInfo *topo_info,
> > >       return x86_apicid_from_topo_ids(topo_info, &topo_ids);
> > >   }
> > > -/*
> > > - * Check whether there's extended topology level (module or die)?
> > > - */
> > > -static inline bool x86_has_extended_topo(unsigned long *topo_bitmap)
> > > -{
> > > -    return test_bit(CPU_TOPO_LEVEL_MODULE, topo_bitmap) ||
> > > -           test_bit(CPU_TOPO_LEVEL_DIE, topo_bitmap);
> > > -}
> > > -
> > 
> > [snip]
> > 
> > > +/*
> > > + * Check whether there's v2 extended topology level (module or die)?
> > > + */
> > > +bool x86_has_v2_extended_topo(X86CPU *cpu)
> > > +{
> > > +    if (cpu->enable_cpuid_0x1f) {
> > > +        return true;
> > > +    }
> > > +
> > > +    return test_bit(CPU_TOPO_LEVEL_MODULE, cpu->env.avail_cpu_topo) ||
> > > +           test_bit(CPU_TOPO_LEVEL_DIE, cpu->env.avail_cpu_topo);
> > > +}
> > > +
> > 
> > I suggest to decouple 0x1f enablement and extended topo check, since as
> > the comment of CPUTopoLevel said:
> > 
> > /*
> >   * CPUTopoLevel is the general i386 topology hierarchical representation,
> >   * ordered by increasing hierarchical relationship.
> >   * Its enumeration value is not bound to the type value of Intel (CPUID[0x1F])
> >   * or AMD (CPUID[0x80000026]).
> >   */
> > 
> > The topology enumeration is generic and is not bound to the vendor.
> 
> I don't quit get your point. All the current usages of
> x86_has_extended_topo() are for CPUID leaf 0x1f, which is an Intel specific
> leaf.

0x1f is just a user of that helper, and AMD's leaf would be another
potential user, even if it is not implemented yet.

What this helper does is check the topology hierarchy set by -smp for
x86 CPUs, and has nothing to do with enabling 0x1f or not. You cannot
falsely report the presence of module/die if -smp doesn't configure such
levels but 0x1f is forcibly enabled.

> Are you saying x86_has_extended_topo() will be used for leaf 0x80000026 for
> AMD as well?
> 
> or maybe I misunderstand the meaning "extend_topo". The extend_topo just
> means the topo level of module and die, and the topo level of smt and core
> are non-extended? 

Any levels that 0xb doesn't cover.

> If so, this is new to me, could I ask where the
> definitions come from? or just QEMU defines them itself?
>
> > [snip]
> > 
> > > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > > index c6cc035df3d8..211a42ffbfa6 100644
> > > --- a/target/i386/cpu.h
> > > +++ b/target/i386/cpu.h
> > > @@ -2110,6 +2110,9 @@ struct ArchCPU {
> > >       /* Compatibility bits for old machine types: */
> > >       bool enable_cpuid_0xb;
> > > +    /* Force to expose cpuid 0x1f */
> > 
> > Maybe "Force to enable cpuid 0x1f"?
> 
> I can change to it.
> 
> > > +    bool enable_cpuid_0x1f;
> > > +
> > >       /* Enable auto level-increase for all CPUID leaves */
> > >       bool full_cpuid_auto_level;i
> > 
> > Regards,
> > Zhao
> > 
>