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. > Thanks, > > /mjt
