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.