From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcJRt-00066R-SP for qemu-devel@nongnu.org; Thu, 30 Jun 2011 11:46:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcJRr-0006mS-V4 for qemu-devel@nongnu.org; Thu, 30 Jun 2011 11:46:37 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:47002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcJRr-0006mM-In for qemu-devel@nongnu.org; Thu, 30 Jun 2011 11:46:35 -0400 Received: by qwj8 with SMTP id 8so1382117qwj.4 for ; Thu, 30 Jun 2011 08:46:34 -0700 (PDT) Sender: Paolo Bonzini From: Paolo Bonzini Date: Thu, 30 Jun 2011 17:46:13 +0200 Message-Id: <1309448777-1447-1-git-send-email-pbonzini@redhat.com> Subject: [Qemu-devel] [RFC PATCH 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). Untested beyond compilation. Paolo Bonzini (4): add support for machine models to specify their migration format add pc-0.14 machine savevm: define new unambiguous migration format Revert "savevm: fix corruption in vmstate_subsection_load()." cpu-common.h | 3 --- qemu-common.h | 2 ++ hw/boards.h | 1 + hw/pc_piix.c | 16 +++++++++++++++- savevm.c | 44 +++++++++++++++++++++++++------------------- 5 files changed, 43 insertions(+), 23 deletions(-) 50,2 Bot -- 1.7.5.2