> This makes sense.
>
> In this case though, the next patch, a62fef5829956 "i386/cpu: Fix cpu
> number overflow in CPUID.01H.EBX[23:16]", becomes a one-liner:
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 2c9517f56d..5e55dd9ee5 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -6828,7 +6828,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
> uint32_t count,
> }
> *edx = env->features[FEAT_1_EDX];
> if (threads_per_pkg > 1) {
> - *ebx |= threads_per_pkg << 16;
> + /* Fixup overflow: max value for bits 23-16 is 255. */
> + *ebx |= MIN(threads_per_pkg, 255) << 16;
> }
> if (!cpu->enable_pmu) {
> *ecx &= ~CPUID_EXT_PDCM;
>
> Is it okay with you, or maybe should I drop this change for 10.0.x
> too?
Yes, it's okay. This commit I should have cc'd stable, as it is indeed a
reported bug.
And after this commit, there're another 2 commits to avoid overflow:
* commit 3e86124e7cb9 ("i386/cpu: Fix overflow of cache topology fields
in CPUID.04H")
* commit 5d21ee453ad8 ("i386/cpu: Honor maximum value for CPUID.
8000001DH.EAX[25:14]")
I think these two could also be stable v10.0.x materials.
Thanks,
Zhao
