On Wed, May 27, 2026 at 09:20:10AM -0300, Fabiano Rosas wrote: > Michael Tokarev <[email protected]> writes: > > > On 27.05.2026 02:57, Alistair Francis wrote: > >> On Tue, 2026-05-26 at 10:26 +0300, Michael Tokarev wrote: > > > >>> This change has been nominated for inclusion into previous stable > >>> releases by Alistar. However I've a concern here: can we add new > >>> fields to older machine descriptions this way, and stay migratable? > >> > >> I was under the impression that we could, but as I write this I start > >> to think that no we can't. > >> > >> We don't have to backport this then > > > > hmm. > > > >>> I understand riscv machine is not versioned. How does migration work > >>> in the first place? > >> > >> As in the virt machine isn't versioned? or `vmstate_riscv_cpu` isn't > >> versioned? > > > > For i386, we've pc-q35-10.0, pc-8.2, etc - versioned after qemu. > > Each version has strictly defined set of properties, and there's > > conversion between different versions when doing cross-version > > migration. So it's possible to migrate a VM when the set of > > properties changes. > > > > I don't see similar construct for riscv. And since we do change > > things in there, modifying set of properties in various areas in > > the migration stream, - I dunno how migration works in riscv qemu > > land. So I'm asking.. :) > > > > There are no migration compatibility guarantees for an unversioned > machine type. Only migration and snapshots from same-version QEMUs are > expected to work in this case. Other scenarios may or may not work. > > > From what I understand, migration should fail when the target qemu > > has different set of properties compared to the current one, - no? > > > > The addition from this patch is in a subsection, so .needed will > determine whether it will be put on the stream. If we backport the > change, then the stable QEMU build will (likely) start sending this > subsection, which the old, non-stable QEMU will not recognize and > migration will fail. Migration from stable-stable would likely work. > > So any stable versions that (would) contain this patch are likely to > block migration from that version into an unpatched QEMU. > > Note that since the machine is unversioned, migration from QEMU x to > QEMU x+1 is already prone to being broken. > > > But if it works, we should apply this patch to older/stable releases, > > there should be no issues in there. > > > > But again, I don't understand the mechanism here. > > > > I'm adding Peter and Fabiano to Cc (maintainers of the migration code), > > -- can you clarify please? > > > > @Peter, I hope I got it right, feel free to correct me.
Agreed with above. If riscv cares about migration compatibilities and the ability to upgrade clusters without interrupting VMs, maybe it's a good idea to start thinking about versioning the machines. Tkanks, -- Peter Xu
