On Fri, Oct 10, 2025 at 08:40:56PM +0300, Michael Tokarev wrote: > Date: Fri, 10 Oct 2025 20:40:56 +0300 > From: Michael Tokarev <[email protected]> > Subject: Re: [RFT PATCH v2 0/2] Fix cross migration issue with missing > features: pdcm, arch-capabilities > > On 9/25/25 19:17, Zhao Liu wrote: > > On Tue, Sep 23, 2025 at 12:41:34PM +0200, Paolo Bonzini wrote: > > > Date: Tue, 23 Sep 2025 12:41:34 +0200 > > > From: Paolo Bonzini <[email protected]> > > > Subject: [RFT PATCH v2 0/2] Fix cross migration issue with missing > > > features: pdcm, arch-capabilities > > > X-Mailer: git-send-email 2.51.0 > > > > > > Add two compatibility properties to restore legacy behavior of machine > > > types > > > prior to QEMU 10.1. Each of them addresses the two changes to CPUID: > > > > > > - ARCH_CAPABILITIES should not be autoenabled when the CPU model > > > specifies AMD > > > as the vendor > > > > > > - specifying PDCM without PMU now causes an error, instead of being > > > silently > > > dropped in cpu_x86_cpuid. > > > > > > Note, I only tested this lightly. > > > > Sorry for late. > > > > 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. > 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? > 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. > 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). So it seems the reverts are unavoidable on v10.0? (Let's see what Paolo and the other maintainers think.) > 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 too will make 10.0.5 => 10.0.6 non-migrateable, just like if > I'll revert 24778b1c7ee7a and 3d26cb65c27190e5 in 10.0. But this way > we will also have these bugs fixed in 10.0. And all subsequent > versions of 10.0 and 10.1 will be migratable again. > > Please, don't be quiet this time, - I need your comments for this > matter, because I don't understand well enough how migration works. > > Cc'ing Peter too, because I'm stuck here and no my questions are > getting answered.. maybe he can help to at least clear some questions. 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 :-(. Thanks, Zhao
