[PATCH] target/i386: move arch_capabilities & pdcm compatibility properties from 10.0 to 9.2 machine type

[PATCH] target/i386: move arch_capabilities & pdcm compatibility properties from 10.0 to 9.2 machine type

[Michael Tokarev]

The two compat properties, introduced by the following commits (f):

 e9efa4a771 target/i386: add compatibility property for arch_capabilities
 6529f31e0d target/i386: add compatibility property for pdcm feature

were added to address migration issues after the following commits (c10.1):

 d3a24134e3 target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
 e68ec29809 i386/cpu: Move adjustment of CPUID_EXT_PDCM before feature_dependencies[] check

which were added in 10.1 and broke migration from 10.0 to 10.1.

However, the 2 changes which required the compat properties, were
mistakenly cherry-picked to 10.0.x stable branch (c10.0):

 24778b1c7e target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
 3d26cb65c2 i386/cpu: Move adjustment of CPUID_EXT_PDCM before feature_dependencies[] check

and were released as v10.0.4 (and v10.0.5).  This breaks migration
from earlier versions to 10.0.4 the same way as it's broken for 10.1
where the two fixes (f) are needed.

However, reverting c10.0 commits from the 10.0.x stable branch will
make that branch further incompatible with itself again, in an opposite
way.

It might be better to accept the current situation and "pretend" that
the c10.0 commits has "always" been in 10.0 branch.  So the fixups (f)
are needed for both 10.0 and 10.1 branches to preserve migration
compatibility from the earlier versions and between 10.0 & 10.1 & next.
So the fixup commits (f) can be applied to both branches, and on top
of that, adjust the machine version for the compat properties from 10.0
to the previous, 9.2, machine type.

This is what this change does.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
---
Note1: this is an alternative to reverting the two changes (c10.0)
from the 10.0.x branch.  If accepted, this will be the first time
in history when we modify machine properties retrospectively (or
I think so, maybe there were other case like this already).

Note2: I still don't understand the implications of this migration
stuff, - what exactly is broken now and what will be broken if this
change is accepted, or if (c10.0) are reverted.  We've quite a matrix
here:

  10.0.3 and before
  10.0.4, 10.0.5 (with c10.0 applied)
  10.0.6 and up (with the fix, either revert of (c10.0) or with 2 fixups on top)
  10.1.1 and before (before (f) is applied)
  10.1.2 and up (with (f) applied and maybe with this fixup applied too)

This set is multiplied further by the number of possible machine versions
used in particular setup - if it was -m pc-10.0 or -m pc-10.1.

We also have backwards migration but I don't care about it at this time.

Note3: It'd be best if we can release a fixed set of versions sooner,
so it's finally known which combination is broken for migration and
in which way.

Note4: due to my lack of understanding of the brokeness and its severity,
I can't decide which way to go from here.  It'd be really nice if I knew
at least, like, 'a->b: dies at migration; c->d: migration succeeds, but
some OSes might start misbehaving due to changed CPU properties' stuff about
the above matrix, - this way, it will be possible to make a better decision.

Thanks, and sorry for the breakage and the long post.

 hw/i386/pc.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 4d6bcbb846..40fb12a3d2 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -87,12 +87,13 @@ const size_t pc_compat_10_1_len = G_N_ELEMENTS(pc_compat_10_1);
 GlobalProperty pc_compat_10_0[] = {
     { TYPE_X86_CPU, "x-consistent-cache", "false" },
     { TYPE_X86_CPU, "x-vendor-cpuid-only-v2", "false" },
-    { TYPE_X86_CPU, "x-arch-cap-always-on", "true" },
-    { TYPE_X86_CPU, "x-pdcm-on-even-without-pmu", "true" },
 };
 const size_t pc_compat_10_0_len = G_N_ELEMENTS(pc_compat_10_0);
 
-GlobalProperty pc_compat_9_2[] = {};
+GlobalProperty pc_compat_9_2[] = {
+    { TYPE_X86_CPU, "x-arch-cap-always-on", "true" },
+    { TYPE_X86_CPU, "x-pdcm-on-even-without-pmu", "true" },
+};
 const size_t pc_compat_9_2_len = G_N_ELEMENTS(pc_compat_9_2);
 
 GlobalProperty pc_compat_9_1[] = {
-- 
2.47.3

Re: [PATCH] target/i386: move arch_capabilities & pdcm compatibility properties from 10.0 to 9.2 machine type

[Zhao Liu]

+Christian (who reported the migration bug) and Perter Xu

On Tue, Oct 14, 2025 at 09:36:47AM +0300, Michael Tokarev wrote:
> Date: Tue, 14 Oct 2025 09:36:47 +0300
> From: Michael Tokarev <mjt@tls.msk.ru>
> Subject: [PATCH] target/i386: move arch_capabilities & pdcm compatibility
>  properties from 10.0 to 9.2 machine type
> X-Mailer: git-send-email 2.47.3
> 
> The two compat properties, introduced by the following commits (f):
> 
>  e9efa4a771 target/i386: add compatibility property for arch_capabilities
>  6529f31e0d target/i386: add compatibility property for pdcm feature
> 
> were added to address migration issues after the following commits (c10.1):
> 
>  d3a24134e3 target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
>  e68ec29809 i386/cpu: Move adjustment of CPUID_EXT_PDCM before feature_dependencies[] check
> 
> which were added in 10.1 and broke migration from 10.0 to 10.1.
> 
> However, the 2 changes which required the compat properties, were
> mistakenly cherry-picked to 10.0.x stable branch (c10.0):
> 
>  24778b1c7e target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
>  3d26cb65c2 i386/cpu: Move adjustment of CPUID_EXT_PDCM before feature_dependencies[] check
> 
> and were released as v10.0.4 (and v10.0.5).  This breaks migration
> from earlier versions to 10.0.4 the same way as it's broken for 10.1
> where the two fixes (f) are needed.
> 
> However, reverting c10.0 commits from the 10.0.x stable branch will
> make that branch further incompatible with itself again, in an opposite
> way.
> 
> It might be better to accept the current situation and "pretend" that
> the c10.0 commits has "always" been in 10.0 branch.  So the fixups (f)
> are needed for both 10.0 and 10.1 branches to preserve migration
> compatibility from the earlier versions and between 10.0 & 10.1 & next.
> So the fixup commits (f) can be applied to both branches, and on top
> of that, adjust the machine version for the compat properties from 10.0
> to the previous, 9.2, machine type.
> 
> This is what this change does.
> 
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
> ---
> Note1: this is an alternative to reverting the two changes (c10.0)
> from the 10.0.x branch.  If accepted, this will be the first time
> in history when we modify machine properties retrospectively (or
> I think so, maybe there were other case like this already).
> 
> Note2: I still don't understand the implications of this migration
> stuff, - what exactly is broken now and what will be broken if this
> change is accepted, or if (c10.0) are reverted.  We've quite a matrix
> here:
> 
>   10.0.3 and before
>   10.0.4, 10.0.5 (with c10.0 applied)
>   10.0.6 and up (with the fix, either revert of (c10.0) or with 2 fixups on top)
>   10.1.1 and before (before (f) is applied)
>   10.1.2 and up (with (f) applied and maybe with this fixup applied too)
> 
> This set is multiplied further by the number of possible machine versions
> used in particular setup - if it was -m pc-10.0 or -m pc-10.1.
> 
> We also have backwards migration but I don't care about it at this time.

Canonical initially reported migration failures between QEMU 10.0 and
10.1, so their 10.0 build lacked the original two fixups.

Adding the compat option to pc_compat_9_2 can help stable v10.0.[4,5],
but Canonical's case will still fail.

I think that if Canonical officially adopts v10.0.[0-3] and hasn't used
v10.0.[4,5], reverting might be a more viable option. If they plan to
use v10.0.[4,5], then the current solution is preferable. Understanding
Canonical's v10.0 status can help evaluate the impact of different
options.

Regards,
Zhao

> Note3: It'd be best if we can release a fixed set of versions sooner,
> so it's finally known which combination is broken for migration and
> in which way.
> 
> Note4: due to my lack of understanding of the brokeness and its severity,
> I can't decide which way to go from here.  It'd be really nice if I knew
> at least, like, 'a->b: dies at migration; c->d: migration succeeds, but
> some OSes might start misbehaving due to changed CPU properties' stuff about
> the above matrix, - this way, it will be possible to make a better decision.
> 
> Thanks, and sorry for the breakage and the long post.
> 
>  hw/i386/pc.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 4d6bcbb846..40fb12a3d2 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -87,12 +87,13 @@ const size_t pc_compat_10_1_len = G_N_ELEMENTS(pc_compat_10_1);
>  GlobalProperty pc_compat_10_0[] = {
>      { TYPE_X86_CPU, "x-consistent-cache", "false" },
>      { TYPE_X86_CPU, "x-vendor-cpuid-only-v2", "false" },
> -    { TYPE_X86_CPU, "x-arch-cap-always-on", "true" },
> -    { TYPE_X86_CPU, "x-pdcm-on-even-without-pmu", "true" },
>  };
>  const size_t pc_compat_10_0_len = G_N_ELEMENTS(pc_compat_10_0);
>  
> -GlobalProperty pc_compat_9_2[] = {};
> +GlobalProperty pc_compat_9_2[] = {
> +    { TYPE_X86_CPU, "x-arch-cap-always-on", "true" },
> +    { TYPE_X86_CPU, "x-pdcm-on-even-without-pmu", "true" },
> +};
>  const size_t pc_compat_9_2_len = G_N_ELEMENTS(pc_compat_9_2);
>  
>  GlobalProperty pc_compat_9_1[] = {
> -- 
> 2.47.3
>