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...@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
> >
>
