On 8/8/2024 10:46 PM, Zhao Liu wrote:
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.
The name of extended_topo is so misleading. At least, it misleads me.
Both Intel and AMD support leaf 0xb and the name of leaf 0xb is
"Extended topology enumeration". And here, x86_has_extended_topo() is
used for topo levels that cannot be covered by 0xb.
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
