From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCYY9-0005CL-Mq
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:01:49 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCYY5-0005A1-0B
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:01:49 -0500
Received: from [199.232.76.173] (port=45529 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCYY4-00059l-P3
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:01:44 -0500
Received: from mail-px0-f204.google.com ([209.85.216.204]:42725)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NCYY4-0003lV-6D
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:01:44 -0500
Received: by pxi42 with SMTP id 42so3276817pxi.5
	for <qemu-devel@nongnu.org>; Mon, 23 Nov 2009 05:01:43 -0800 (PST)
Message-ID: <4B0A87B2.1030507@codemonkey.ws>
Date: Mon, 23 Nov 2009 07:01:38 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <4B0952C9.9010803@redhat.com>
	<4B095D86.700@codemonkey.ws>	<hec6i6$j3r$1@ger.gmane.org>
	<4B09F0CA.3060705@codemonkey.ws>	<20091123082659.GC2999@redhat.com>
	<m3iqd14edf.fsf@neno.neno>
In-Reply-To: <m3iqd14edf.fsf@neno.neno>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: Live migration protocol, device features,
	ABIs and   other beasts
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.gnu.org/pipermail/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: Juan Quintela <quintela@trasno.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>

Juan Quintela wrote:
> Gleb Natapov <gleb@redhat.com> wrote:
>   
>> On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
>>     
>>> Paolo Bonzini wrote:
>>>       
>>>>> I don't see how this fixes anything. If you used feature bits, how do
>>>>> you migrate from a version that has a feature bit that an older version
>>>>> doesn't know about? Do you just ignore it?
>>>>>           
>>>> I'd go with chunk instead of feature bits, specifying them like in
>>>> the PNG specification:
>>>>         
>>> You mean, each device would have multiple sections?  We already use
>>> chunks for each device state.
>>>
>>>       
>> Each device can send device info in multiple formats (each format with
>> its own ID) and destination will choose the one it supports.
>>     
>
> RAM anyone?  You send 1GB of info in different formats, just in case :)
>
> In this case, I think that the only two realistic solutions are to
> increase negotiation during migration:
>
> - source -> target: I can save this devices with this versions:
>    "cpu" 10 - 12
>    "apic" 3
>    "ide" 2-4
>    "virtio-net" 5-10
>    ....
> - target -> source:
>    * I don't support "virtio-net" at all -> failed migration
>    * send it as:
>       "cpu" 11
>       "apic" 3
>       "ide" 2
>       "virtio-net" 10
>      thankyou very much :)
>   

I'm not at all convinced that you can downgrade the version of a device 
without exposing a functional change to a guest.  In fact, I'm pretty 
certain that it's provably impossible.  Please give a counter example of 
where this mechanism would be safe.

> Having subversions for downstream is a different problem that needs to
> be fixed.
>   

Yup.  However, I believe the problem is addresses is really what's 
driving this discussion of optional features.

Regards,

Anthony Liguori

> Later, Juan.
>