From: Anthony Liguori <anthony@codemonkey.ws>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 0.15 0/4] Fix subsection ambiguity in the migration format
Date: Tue, 02 Aug 2011 18:06:58 -0500 [thread overview]
Message-ID: <4E388312.4070208@codemonkey.ws> (raw)
In-Reply-To: <1311953585-16021-1-git-send-email-pbonzini@redhat.com>
On 07/29/2011 10:33 AM, Paolo Bonzini wrote:
> With the current migration format, VMS_STRUCTs with subsections
> are ambiguous. The protocol cannot tell whether a 0x5 byte after
> the VMS_STRUCT is a subsection or part of the parent data stream.
> In the past QEMU assumed it was always a part of a subsection; after
> commit eb60260 (savevm: fix corruption in vmstate_subsection_load(),
> 2011-02-03) the choice depends on whether the VMS_STRUCT has subsections
> defined.
>
> Unfortunately, this means that if a destination has no subsections
> defined for the struct, it will happily read subsection data into
> its own fields. And if you are "lucky" enough to stumble on a
> zero byte at the right time, it will be interpreted as QEMU_VM_EOF
> and migration will be interrupted with half-loaded state.
>
> There is no way out of this except defining an incompatible
> migration protocol. Not-so-long-term we should really try to define
> one that is not a joke, but the bug is serious so we need a solution
> for 0.15. A sentinel at the end of embedded structs does remove the
> ambiguity.
I've thought about this very carefully now. I just don't feel
comfortable making a protocol change in an rc window for a series that
hasn't spent any time in master.
This issue needs to be fixed for 0.15, but there's a simpler solution as
we currently only have two uses of subsections in the tree today. I'll
send out a patch that bumps those two migration states to a new version
and eliminates the subsection usage entirely.
If we can agree on that for 0.15, I'm happy to take this series into
master but we should also consider other possibilities too for fixing
the problem.
Regards,
Anthony Liguori
>
> Of course, this can be restricted to new machine models, and this
> is what the patch series does. (And note that only patch 3 is specific
> to the short-term solution, everything else is entirely generic).
>
> I am still proposing this for 0.15. Tested new on new, 0.14 on new
> pc-0.14, new pc-0.14 on 0.14; also for v1 the same combinations on RHEL.
>
> v1->v2:
> added qemu_current_migration_format() and
> QEMU_VM_FILE_VERSION_0_14.
>
> Paolo Bonzini (4):
> add support for machine models to specify their migration format
> add pc-0.14 machine
> savevm: define new unambiguous migration format
> Partially revert "savevm: fix corruption in
> vmstate_subsection_load()."
>
> cpu-common.h | 3 ---
> hw/boards.h | 4 ++++
> hw/pc_piix.c | 15 ++++++++++++++-
> qemu-common.h | 3 +++
> savevm.c | 46 ++++++++++++++++++++++++++++++++--------------
> 5 files changed, 53 insertions(+), 18 deletions(-)
>
prev parent reply other threads:[~2011-08-02 23:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-29 15:33 [Qemu-devel] [PATCH v2 0.15 0/4] Fix subsection ambiguity in the migration format Paolo Bonzini
2011-07-29 15:33 ` [Qemu-devel] [PATCH v2 0.15 1/4] add support for machine models to specify their " Paolo Bonzini
2011-07-29 15:33 ` [Qemu-devel] [PATCH v2 0.15 2/4] add pc-0.14 machine Paolo Bonzini
2011-07-29 15:33 ` [Qemu-devel] [PATCH v2 0.15 3/4] savevm: define new unambiguous migration format Paolo Bonzini
2011-07-29 15:33 ` [Qemu-devel] [PATCH v2 0.15 4/4] Partially revert "savevm: fix corruption in vmstate_subsection_load()." Paolo Bonzini
2011-08-02 23:06 ` Anthony Liguori [this message]
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=4E388312.4070208@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).