From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RASXv-0007Lp-HV for qemu-devel@nongnu.org; Sun, 02 Oct 2011 16:22:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RASXu-0000xI-13 for qemu-devel@nongnu.org; Sun, 02 Oct 2011 16:21:59 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:46713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RASXt-0000xC-MQ for qemu-devel@nongnu.org; Sun, 02 Oct 2011 16:21:57 -0400 Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Sun, 2 Oct 2011 14:21:51 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p92KLmm6146650 for ; Sun, 2 Oct 2011 14:21:49 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p92KLmUq027168 for ; Sun, 2 Oct 2011 14:21:48 -0600 Message-ID: <4E88C7DB.9090105@linux.vnet.ibm.com> Date: Sun, 02 Oct 2011 16:21:47 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: aliguori@linux.vnet.ibm.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" > 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