From: Peter Xu <peterx@redhat.com>
To: Alexandr Moshkov <dtalexundeer@yandex-team.ru>
Cc: qemu-devel@nongnu.org,
"yc-core@yandex-team.ru" <yc-core@yandex-team.ru>,
Fabiano Rosas <farosas@suse.de>
Subject: Re: [PATCH v2] vmstate: fix subsection load name check
Date: Mon, 2 Mar 2026 12:36:55 -0500 [thread overview]
Message-ID: <aaXKt87sJS5Bog5B@x1.local> (raw)
In-Reply-To: <20260302070626.613396-1-dtalexundeer@yandex-team.ru>
On Mon, Mar 02, 2026 at 12:06:26PM +0500, Alexandr Moshkov wrote:
> When loading a subset, its name is checked for the parent prefix. The
> following bug may occur here:
>
> Let's say there is a vmstate named "virtio-blk", it has a subsection
> named "virtio-blk/subsection", and it also has another vmstate named
> "virtio" in the fields.
> Then, during the migration, when trying to load this subsection for
> "virtio", the prefix condition will pass for "virtio-blk/subsection" and
> then the migration will break, because this vmstate does not have such a
> subsection.
>
> In other words, if a field inside vmstate1 is set via vmstate2 with a
> name that is a prefix of the parent vmstate, then the field can "steal"
> a subsection belonging to the parent state.
>
> Looks like it happens because migration stream for "virtio-blk" looks
> like this:
>
> [virtio-blk header] [virtio-blk fields] [virtio-blk subsections]
>
> "virtio-blk" contains "virtio" field, so migration stream is:
>
> [virtio-blk header] [virtio header] [virtio fields] [virtio
> subsections] [virtio-blk subsections]
>
> And when we load the subsections of the "virtio" device,
> vmstate_subsection_load() uses qemu_peek_byte() to try to figure out if
> this is his subsection. This is where we encounter an error.
>
> Thus, the error occurs due to the fact that vmsd does not know how many
> subsections it has when loading (this does not appear anywhere in the
> migration stream), so it tries to load all the appropriate ones by
> names.
>
> Fix it by checking `/` at the end of idstr.
>
> Signed-off-by: Alexandr Moshkov <dtalexundeer@yandex-team.ru>
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
next prev parent reply other threads:[~2026-03-02 17:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 7:06 [PATCH v2] vmstate: fix subsection load name check Alexandr Moshkov
2026-03-02 17:36 ` Peter Xu [this message]
2026-03-06 13:46 ` Fabiano Rosas
2026-03-10 5:32 ` Alexandr Moshkov
2026-03-10 13:27 ` Alexandr Moshkov
2026-03-10 13:39 ` Peter Maydell
2026-03-10 18:00 ` Peter Xu
2026-03-11 6:53 ` Vladimir Sementsov-Ogievskiy
2026-03-11 15:05 ` Peter Xu
2026-03-12 6:30 ` Vladimir Sementsov-Ogievskiy
2026-03-12 15:34 ` Peter Xu
2026-03-12 16:34 ` Vladimir Sementsov-Ogievskiy
2026-03-12 18:13 ` Peter Xu
2026-03-12 18:27 ` Peter Maydell
2026-03-12 19:25 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaXKt87sJS5Bog5B@x1.local \
--to=peterx@redhat.com \
--cc=dtalexundeer@yandex-team.ru \
--cc=farosas@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=yc-core@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.