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/[email protected]/ 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_qeol3g33kdsnh...@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
