On Tue, Oct 14, 2025 at 12:49 PM Hector Cao <[email protected]> wrote: > > > > On Mon, Oct 13, 2025 at 7:22 PM Michael Tokarev <[email protected]> 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. > > 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)
Yes, I agree. In my opinion reverting is the best option, because it makes the machine types as constant as possible. Any change in the machine types is a bug and the fix is to revert to the previous situation. Paolo
