Re: [PATCH v1] target/riscv: Add mseccfg to VMStateDescription

[Peter Xu <peterx@redhat.com>]

On Wed, May 27, 2026 at 09:20:10AM -0300, Fabiano Rosas wrote:
> Michael Tokarev <mjt@tls.msk.ru> 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