From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RATFT-0006jD-Ea for qemu-devel@nongnu.org; Sun, 02 Oct 2011 17:07:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RATFR-00087F-OJ for qemu-devel@nongnu.org; Sun, 02 Oct 2011 17:06:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RATFR-000875-HD for qemu-devel@nongnu.org; Sun, 02 Oct 2011 17:06:57 -0400 Date: Sun, 2 Oct 2011 23:08:03 +0200 From: "Michael S. Tsirkin" Message-ID: <20111002210802.GC8072@redhat.com> References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <4E88C7DB.9090105@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E88C7DB.9090105@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: aliguori@linux.vnet.ibm.com, Michael Roth , qemu-devel@nongnu.org On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger wrote: > > >4) Implement the BERVisitor and make this the default migration protocol. > > > >Most of the work will be in 1), though with the implementation in this series we should be able to do it incrementally. I'm not sure if the best approach is doing the mechanical phase 1 conversion, then doing phase 2 sometime after 4), doing phase 1 + 2 as part of 1), or just doing VMState conversions which gives basically the same capabilities as phase 1 + 2. > > > >Thoughts? > Is anyone working on this? If not I may give it a shot (tomorrow++) > for at least some of the primitives... for enabling vNVRAM metadata > of course. Indefinite length encoding of constructed data types I > suppose won't be used otherwise the visitor interface seems wrong > for parsing and skipping of extra data towards the end of a > structure if version n wrote the stream and appended some of its > version n data and now version m < n is trying to read the struct > and needs to skip the version [m+1, n ] data fields ... in that case > the de-serialization of the stream should probably be stream-driven > rather than structure-driven. > > Stefan Yes I've been struggling with that exactly. Anthony, any thoughts? -- MST