Re: [PATCH v2] vmstate: fix subsection load name check

[Peter Xu <peterx@redhat.com>]

On Thu, Mar 12, 2026 at 07:34:34PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hmm. Probably, that this is the subsection, that exist only in our downstream.
> I don't know, was it mentioned clearly before, sorry if not.

Ah.. Looks like it was not mentioned in the latest version posted:

https://lore.kernel.org/all/20260312102626.891359-1-dtalexundeer@yandex-team.ru/

Let's always mention this, because it's important piece of info, e.g. to
know upstream has yet no reproducer.

> This subsection just not exist in master, and we are not going to upstream it.
> So, for upstream it's a "theoretical" bug in a protocol, which may be triggered in
> some future moment. And that's why there is not specific case in commit message
> but only assumption "Let's say there is a vmstate ...".

In this case, for upstream we almost only lose but yet unknown gain with
this fix then, because we stop throwing useful info for unknown new
subsections, as PeterM pointed out:

https://lore.kernel.org/all/CAFEAcA_mzXDdz_xjPnZ9Kc4K01Aoss_OH_qEoL3G33KdsnHrLw@mail.gmail.com/

But I agree it is a potential issue, if we cannot justify QEMU can never
hit it.

Sending "how many subsections are there" is one viable option as you said,
but it only solves this small problem, and knowing that number requires src
QEMU looping over the subsections twice so a bit awkward (first time we
need to kickoff ".needed()" hooks to do the counting; not all will be sent).

The other way is to provide level information somehow in the stream.

Say, we could attach START/END markers for each VMSD to be dumped.  That
may be able to help in other cases too, e.g. when we accidentally grow some
VMSD fields breaking migration, then IIUC dest QEMU can provide a more
accurate error message when it knows the bound of current VMSD that is
being loaded.

But I'm also not sure if this is worth it yet to fix an imaginary problem.

-- 
Peter Xu