On 17.07.2025 06:06, Zhao Liu wrote:
Hi!
Previous incarnation of this patch were Cc'd qemu-stable@, as it were
supposed to be picked up for the stable qemu series. However, this
incarnation is not Cc'd to stable, and, most importantly, it relies
on a feature which was introduced after all released qemu versions.
Namely, vendor_cpuid_only_v2 is past v10.0.0, which is commit
216d9bb6d7716 "i386/cpu: Add x-vendor-cpuid-only-v2 option for
compatibility".
Should I omit this change for stable-10.0 series, or should it be
modified to work in 10.0?
Hi Michael, considerring current fix is covered by compat option,
it's not fit to be backported to the previous version.
This issue has existed for a very long time, and the feedback received
on this is currently one case and it based on a specific topology
configuration, so the impact is limited. Therefore, in this patch
version, I fixed it with the newly added compat option, which also
avoids the controversy about the impact of migration.
So I think you could omit this change for stable-10.0 series, if it's
also okay with Paolo.
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?
Thanks,
/mjt
