[PATCH for v10.1] i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1]

[PATCH for v10.1] i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1]

[Zhao Liu]

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 <mjt@tls.msk.ru>
Inspired-by: Chuang Xu <xuchuangxclwt@bytedance.com>
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 <zhao1.liu@intel.com>
---
 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 251d5760a0bd..673f8583c809 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.34.1

Re: [PATCH for v10.1] i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1]

[Michael Tokarev]

On 04.08.2025 08:35, Zhao Liu wrote:
> 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 <mjt@tls.msk.ru>
> Inspired-by: Chuang Xu <xuchuangxclwt@bytedance.com>
> 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 <zhao1.liu@intel.com>
> ---
>   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 251d5760a0bd..673f8583c809 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;

Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>

Thank you!

/mjt

Re: [PATCH for v10.1] i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1]

[Philippe Mathieu-Daudé]

On 4/8/25 07:35, Zhao Liu wrote:
> 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 <mjt@tls.msk.ru>
> Inspired-by: Chuang Xu <xuchuangxclwt@bytedance.com>
> 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 <zhao1.liu@intel.com>
> ---
>   target/i386/cpu.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)

Patch queued, thanks!