On 12.03.26 18:34, Peter Xu wrote:
On Thu, Mar 12, 2026 at 09:30:35AM +0300, Vladimir Sementsov-Ogievskiy wrote:
You say
.. always pop the VMSD stack then the upper layer may read the SUBSECTION byte
anywhere.
But it actually can be anything. Of course probability is small that some
another state
looks like QEMU_VM_SUBSECTION + <existing subsection name>, but we don't have
actual
guarantee for it in the protocol.
Probably, we may also add a protocol change (with some global state property,
set to true in new MT) to add a number of subsections into section state, to be
sure how many of them we have in the stream.
Yes, I believe it's always possible to change the streaming protocol to
make it even clearer. Actually, that's what I was picturing before I read
your previous reply.
For doing that, I wonder if we should just fix "this specific problem" or
"the bigger problem".
The bigger problem here, at least to me, is migration streaming lacks level
information - virtio can wrongly treat that piece of info as its own
subsection only because the stream doesn't tell which level it's in..
It's a common issue for migration stream, so I wonder if we need to break
the streaming protocol then whether we should do even further than that.
That is the part where I think what you suggested in the previous email may
be the easy way to go (plus, removing the name check completely).
But let me double check with you on one thing: before any fix, this problem
will happen even during a migration between two latest QEMU that supports
that new subsection of virtio-blk, am I right?
I am curious why this problem is only reported until today, rather than
when the new subsection was developed. I wonder if I still miss something
that I didn't notice..
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.
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 ...".
--
Best regards,
Vladimir
