From 4e5d58969ed6927a7f1b08ba6223c34c8b990c92 Mon Sep 17 00:00:00 2001 From: Zhao Liu Date: Mon, 4 Aug 2025 13:35:48 +0800 Subject: [PATCH] target/i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1] MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Currently, the addressable ID encoding for CPUID[0x1].EBX[bits 16-23] (Maximum number of addressable IDs for logical processors in this physical package) is covered by vendor_cpuid_only_v2 compat property. The previous consideration was to avoid breaking migration and this compat property makes it unfriendly to backport the commit f985a1195ba2 ("i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX [23:16]"). However, NetBSD booting is broken since the commit 88dd4ca06c83 ("i386/cpu: Use APIC ID info to encode cache topo in CPUID[4]"), because NetBSD calculates smt information via `lp_max` / `core_max` for legacy Intel CPUs which doesn't support 0xb leaf, where `lp_max` is from CPUID[0x1].EBX.bits[16-23] and `core_max` is from CPUID[0x4].0x0.bits[26 -31]. The commit 88dd4ca0 changed the encoding rule of `core_max` but didn't update `lp_max`, so that NetBSD would get the wrong smt information, which leads to the module loading failure. Luckily, the commit f985a1195ba2 ("i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]") updated the encoding rule for `lp_max` and accidentally fixed the NetBSD issue too. This also shows that using CPUID[0x1] and CPUID[0x4].0x0 to calculate HT/SMT information is a common practice to detect CPU topology on legacy Intel CPUs. Therefore, it's necessary to backport the commit f985a1195ba2 to previous stable QEMU to help address the similar issues as well. Then the compat property is not needed any more since all stable QEMUs will follow the same encoding way. So, in CPUID[0x1], move addressable ID encoding out of compat property. Reported-by: Michael Tokarev Inspired-by: Chuang Xu Fixes: commit f985a1195ba2 ("i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3061 Signed-off-by: Zhao Liu Reviewed-by: Michael Tokarev Tested-by: Michael Tokarev Message-ID: <20250804053548.1808629-1-zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé --- target/i386/cpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 251d5760a0..673f8583c8 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -7885,8 +7885,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, * count, but Intel needs maximum number of addressable IDs for * logical processors per package. */ - if (cpu->vendor_cpuid_only_v2 && - (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) { + if ((IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) { num = 1 << apicid_pkg_offset(topo_info); } else { num = threads_per_pkg; -- 2.47.2