From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qmp3x-0005K0-1Z for qemu-devel@nongnu.org; Fri, 29 Jul 2011 11:33:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qmp3v-0001D0-TJ for qemu-devel@nongnu.org; Fri, 29 Jul 2011 11:33:21 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:48867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qmp3v-0001Cq-Er for qemu-devel@nongnu.org; Fri, 29 Jul 2011 11:33:19 -0400 Received: by gxk26 with SMTP id 26so3117836gxk.4 for ; Fri, 29 Jul 2011 08:33:19 -0700 (PDT) Sender: Paolo Bonzini From: Paolo Bonzini Date: Fri, 29 Jul 2011 17:33:01 +0200 Message-Id: <1311953585-16021-1-git-send-email-pbonzini@redhat.com> Subject: [Qemu-devel] [PATCH v2 0.15 0/4] Fix subsection ambiguity in the migration format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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. 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(-) -- 1.7.6