From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qmmra-0005dv-UW for qemu-devel@nongnu.org; Fri, 29 Jul 2011 09:12:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qmmra-0005kR-2R for qemu-devel@nongnu.org; Fri, 29 Jul 2011 09:12:26 -0400 Received: from mail-pz0-f43.google.com ([209.85.210.43]:57095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmmrZ-0005kL-Sc for qemu-devel@nongnu.org; Fri, 29 Jul 2011 09:12:26 -0400 Received: by pzk1 with SMTP id 1so6667252pzk.30 for ; Fri, 29 Jul 2011 06:12:24 -0700 (PDT) Message-ID: <4E32B1B5.3050402@codemonkey.ws> Date: Fri, 29 Jul 2011 08:12:21 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1309448777-1447-1-git-send-email-pbonzini@redhat.com> <1309448777-1447-4-git-send-email-pbonzini@redhat.com> In-Reply-To: <1309448777-1447-4-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 3/4] savevm: define new unambiguous migration format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 06/30/2011 10:46 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. > > There is no way out of this except defining an incompatible > migration protocol with a sentinel at the end of embedded structs. > Of course, this is restricted to new machine models. > > Signed-off-by: Paolo Bonzini > --- > hw/pc_piix.c | 6 ++++++ > savevm.c | 27 +++++++++++++++++++-------- > 2 files changed, 25 insertions(+), 8 deletions(-) > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c > index 18cc942..d8d629c 100644 > --- a/hw/pc_piix.c > +++ b/hw/pc_piix.c > @@ -271,6 +271,7 @@ static QEMUMachine pc_machine_v0_14 = { > .desc = "Standard PC", > .init = pc_init_pci, > .max_cpus = 255, > + .migration_format = 3, > }; Please introduce a macro so this code is readable. We have other machines that support migration in other archs too. Regards, Anthony Liguori