From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=46680 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PmdEX-0005n6-EV
	for qemu-devel@nongnu.org; Mon, 07 Feb 2011 21:23:14 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PmdEW-0000bI-4v
	for qemu-devel@nongnu.org; Mon, 07 Feb 2011 21:23:13 -0500
Received: from mail-wy0-f173.google.com ([74.125.82.173]:50903)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PmdEV-0000bE-UM
	for qemu-devel@nongnu.org; Mon, 07 Feb 2011 21:23:12 -0500
Received: by wyg36 with SMTP id 36so5506005wyg.4
	for <qemu-devel@nongnu.org>; Mon, 07 Feb 2011 18:23:11 -0800 (PST)
Message-ID: <4D50A90C.1060701@codemonkey.ws>
Date: Mon, 07 Feb 2011 20:23:08 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <20110207160751.GC25106@redhat.com>
	<4D504925.3000807@codemonkey.ws>
	<20110207195315.GA28096@redhat.com>
	<4D505C92.5040904@codemonkey.ws>
	<20110207215203.GA28658@redhat.com>
In-Reply-To: <20110207215203.GA28658@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: new->old version migration
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>, Alex Williamson <alex.williamson@redhat.com>, qemu list <qemu-devel@nongnu.org>, Juan Quintela <quintela@redhat.com>

On 02/07/2011 03:52 PM, Michael S. Tsirkin wrote:
> How does it? We need to know we are saving in 0.13
> format and skip the new subsection, otherwise
> 0.13 will see a subsection it does not recognize
> and exit.
>    

If you used subsections for flow control, presumably you would only send 
the new savevm data if you had data buffered.

If you add a qdev property to enable/disable flow control, then if it's 
disabled, you naturally would never send the subsection because you'd 
never buffer data.  So no explicit code is needed to support migration.

The difficult case is when you truly need to change the savevm version.  
I don't think we have a proper fix for this because versions are linear 
so the proposed patch certainly wouldn't be a good way to do it.  if 
flow_control=0 causes savevm 3 to be used instead of 4, and then the 
next_feature=0 causes savevm 4 to be used instead of 5, the semantics of 
flow_control=0,next_feature=1 becomes problematic.

But as long as the feature has isolated state, we can solve the problem 
robustly with subsections.

Regards,

Anthony Liguori

> We also need API to add subsections without vmstate,
> because virtio serial wasn't yet converted.
>
>