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

[Peter Xu <peterx@redhat.com>]

On Fri, May 29, 2026 at 10:43:13AM +0300, Michael Tokarev wrote:
> [Trimmed the Cc list a bit]
> 
> On 27.05.2026 15:20, Fabiano Rosas wrote:
> 
> > 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.
> ..
> > 
> > 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.
> 
> Yeah, this was my understanding too.
> 
> And given all the above, I think we should apply the fixes to the
> stable series, and treat this as changing version (the version is
> actually changed, but only the minor version).  Yes, the VMs wont
> be migratable between 10.0.9 and 10.0.10, exactly like it was
> not-migratable between 10.0.x and 10.1.x.  Because basically, with
> no versioned machines, there's basically no migration capability
> between different qemus *at all*.
> 
> When we do have versioned machines, we can't add fields to previous
> versions anymore, exactly because of the migration guarantees.  But
> as long as we don't, there's no guarantees at all.  And the only
> place where migration can be done is between different hosts with
> the same qemu versions.
> 
> The above description leaves one question still.  What happens when
> migrating from unpatched qemu to a patched qemu?  Will the migration
> fail due to missing field, or succeed, making the missing field to
> have a default value?
> 
> If it will succeed, then we definitely should add the field to fix
> the original issue.
> 
> BTW, can't we just skip, at the receive end, fields we don't know about?

We don't have enough info to skip.

We have headers for VMSD, we don't have headers for VMSD fields.  We
currently dump fields with pure binary streams.  It means when there's a
new field added to migration stream, dest QEMU has no way to know it's a
new field, it'll treat it as the next thing it expects to see, which can be
anything.  We still have the VMSD footer to guard us making sure it don't
bleed outside of the current VMSD, though.

> 
> But all this is.. well... sort of moot for this very change already.
> 
> I haven't realized that this discussion is about a change which I
> *already* applied (I wanted to revert it until this question settles,
> but I forgot to do that!).  And meanwhile, I released the next set
> of stable qemu releases, with the changes in question (two of them)
> applied.  It wasn't my intention (or else I'd not start this
> discussion in the first place, obviously).
> 
> So we do have this migration breakage already, "thanks" to my sloppiness.
> 
> And I don't want to break things for users for no reason.  The original
> issue were described as a security issue even, so there's a reason to
> fix it.  I think.
> 
> But in the future I'll try to be more careful about such things.
> Again, understanding the machinery and consequences helps here too.

Before machine versioning is introduced, this looks like the right thing to
do.

Thanks,

-- 
Peter Xu