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.. -- Peter Xu
