Re: [RFT PATCH v2 0/2] Fix cross migration issue with missing features: pdcm, arch-capabilities

[Hector Cao <hector.cao@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 7978 bytes --]

On Mon, Oct 13, 2025 at 7:22 PM Michael Tokarev <mjt@tls.msk.ru> wrote:

> On 10/13/25 10:22, Zhao Liu wrote:
> > On Fri, Oct 10, 2025 at 08:40:56PM +0300, Michael Tokarev wrote:
> ..>>> I found the previous 2 fixes were merged into stable 10.0:
> >>>
> >>> 24778b1c7ee7aca9721ed4757b0e0df0c16390f7
> >>> 3d26cb65c27190e57637644ecf6c96b8c3d246a3
> >>>
> >>> Should stable 10.0 revert these 2 fixes, to ensure migration
> >>> compatibility?
> >
> > Sorry for late...just return from vacation.
>
> I returned from vacation today too :)
>
> >> Now when I think about it.
> >>
> >> There were at least 2 point releases of 10.0.x (10.0.4 & 10.0.5)
> >> with these 2 patches already.
> >
> > EMM, it seems 10.0.x (x < 4) can't migrate to 10.0.y (4 <= y <= 5),
> > right? If so, could we treat this behavior as a regression?
>
> It is a regression in 10.0.4 indeed.  But it already lasted for
> 2 stable releases (10.0.4 & 10.0.5).  So by reverting the above
> mentioned two changes in 10.0.6, we'll make yet another regression,
> now when migrating from 10.0.[45] to 10.0.6. This is why I thought
> it might be an idea to keep just one regression in 10.0.x, so to
> say.  Especially since these changes already fixes issues with
> existing guests, so by reverting them, we'll bring them back to
> 10.0.x.
>
> It is an either-or combination.  It is not bad either way, I'm just
> thinking what is best currently.
>
> And with my limited understanding of the migration issue in the context
> (for which I asked for clarification some 5 or 6 times already), it
> feels to me like "pretending" these above 2 mentioned above patches has
> always been part of 10.0.x, - declare that migration wont work from
> 10.0.[1-3] (or [1-5]?) to subsequent versions, and be done with it.
>
> And modify the 2 properties introduced by:
>
> 6529f31e0d target/i386: add compatibility property for pdcm feature
> e9efa4a771 target/i386: add compatibility property for arch_capabilities
>
> to be part of pc_compat_9_2 machine, not 10.0..


> Hopefully it's understandable what I mean.
>
>
Hello Michael,

IIUC, there is no perfect solution that makes migration work for all
combinations
of versions as you already pointed out.
Reverting the two faulty commits in 10.0.x will reduce the scope of
migration failures (10.0.x -> 10.0.y / 10.1.z)

You seem to propose to backport the migration fixes (with compatibility
properties) back to 10.0.y
but I don't know if it is possible since only 10.0 machine type is
available.

Apply these compatibility properties only in 9.2 (and older) might make
sense IMHO since 10.0.y behaves the same way than 10.1

>> Reverting them in 10.0 will make
> >> 10.0 to be non-migratable with itself (10.0.5 can't be migrated
> >> to 10.0.6 if we'll release 10.0.6 with these 2 patches reverted).
> >>
> >> Also, as far as I can see (and I asked about this some 5 times
> >> already, with no one answering - is it that difficult?) - we
> >> should pick this series (pdcm, arch-capabilities) to 10.1.x stable
> >> series too, since we can't migrate from previous versions to 10.1
> >> which has the two changes mentioned above.
> >
> > I think so. in this series, Paolo added compat options in pc_compat_10_0
> > so it should be picked to stable v10.1.
>
> Again, I asked about this some 5 times already, with no single
> answer.
>
> >> It looks to me - since the breakage is already done, and both 10.0
> >> and 10.1 is broken, we should declare the current situation as a
> >> status quo, and do the following:
> >>
> >> 1. keep the above mentioned 24778b1c7ee7a and 3d26cb65c27190e5 in
> >>     10.0.x (instead of reverting them);
> >>
> >> 2. pick up this 2 patches (fix cross migration issue with missing
> >>     pdcm, arch-capabilities) to 10.1.x (it should be done either way,
> >>     I think);
> >
> > IIUC, if we picked current compat options to stable v10.1, then stable
> > v10.1 requires previous v10.0 sets the pdcm & arch-cap bits (i.e., do
> > not apply the fixes or revert the previous fix).
>
> Ugh.  Confusion++ :)  As you wrote yourself right above, "Paolo added
> compat options in pc_compat_10_0, so it should be picked up to stable
> 10.1".  This point "2" is exactly this case I'm talking about.  Two
> commits:
>
> 6529f31e0d target/i386: add compatibility property for pdcm feature
> e9efa4a771 target/i386: add compatibility property for arch_capabilities
>
> should be picked up for 10.1.x.
>
> This "2" point is not (yet) about 10.0.x.
>
>
> > So it seems the reverts are unavoidable on v10.0?
> >
> > (Let's see what Paolo and the other maintainers think.)
>
> For 10.0, there are 2 either-or options: either we revert, or we
> pretend these has always been in 10.0.x and compensate, like I described
> in my previous email in this thread (to which you're replying) and
> re-describing now.
>
> >> 3. on top of these 2 "missing features: pdcm, arch-capabilities",
> >>     make the crossing line for before-10.0, not for before-10.1 series,
> -
> >>     ie, consider 10.0 *also* has these properties, but 9.2 and before
> >>     are not.
>
> > This issue is indeed quite tricky. Sometimes people (including myself)
> > assume that backporting fixes to the stable branch can avoid adding a
> > compat option. Now it seems the compat option is the better choice, as
> > users need to ensure migration rather than downtime before upgrading to
> > the stable version :-(.
> It's a good (hopefully) lesson for me myself, - I blindly picked up
> a change which felt like an innocent (I even mentioned that in a commit
> - it's a "cleanup patch") - just so a subsequent change in this area
> applies cleanly.  But it wasn't a cleanup, and it wasn't trivial at
> all.  So I must be much more careful the next time.  I'm talking about
> 3d26cb65c2 "Move adjustment of CPUID_EXT_PDCM..".
>
> Speaking of the other change - it fixed a real bug which I hit myself,
> and I had no idea it's tricky - actually no one had this idea until
> e9efa4a771 "property for arch_capabilities".  So yes, this is a "sh*t
> happens" case :)
>
>
> Ok.
>
> So, back to the situation and the plan (two of them).
>
>
> 1. It looks like we agree we should pick
>
> 6529f31e0d target/i386: add compatibility property for pdcm feature
> e9efa4a771 target/i386: add compatibility property for arch_capabilities
>
> to 10.1.x, to make migration from older versions to 10.1.x work.
>
>
> 2.  For 10.0.x, we've two options:
>
>   2.a.  Revert
>      e9efa4a771 "do not expose ARCH_CAPABILITIES"
>      3d26cb65c2 "Move adjustment of CPUID_EXT_PDCM"
>    as you initially suggested and already reviewed.
>
>    This will make 10.0.[45] "bad" wrt migration, and will re-create the
>    issues these 2 commits fixed, but will make next 10.0.x as good as
>    initial 10.0.0 wrt migration.
>
>   2.b.  Instead of reverting these two which are already in 10.0.[45],
>    pretend 10.0 always had these 2 commits, and adjust subsequent
>    qemu versions just like we did with 2 "add compatibility property"
>    changes, but make it to be 9.2-compat property, not 10.0-compat
>    property.
>
>    This - as far as I can see - will make 10.0.[0-3] to be "bad" wrt
>    migration, but not subsequent 10.0.x ones.  And will keep the bugs
>    fixed in 10.0.x too.
>
> But again, I don't understand the migration logic well, so don't know
> if it even makes sense.  2.b, if deemed to be good, will be the first
> in history (I think) to introduce compat properties for past machine
> types.
>
> Please excuse me for so much text :)
>
> Thank you!
>
> /mjt
>


-- 
Hector CAO
Software Engineer – Server Team / Virtualization
hector.cao@canonical.com
https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao
<https://launchpad.net/~hectorcao>

<https://launchpad.net/~hectorcao>

[-- Attachment #2: Type: text/html, Size: 10391 bytes --]