From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCdti-0005NT-DO
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:44:26 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCdtd-0005LY-TS
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:44:26 -0500
Received: from [199.232.76.173] (port=58134 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCdtd-0005LR-HO
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:44:21 -0500
Received: from mail-bw0-f228.google.com ([209.85.218.228]:35190)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NCdtd-0004lp-5A
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:44:21 -0500
Received: by bwz28 with SMTP id 28so6005900bwz.17
	for <qemu-devel@nongnu.org>; Mon, 23 Nov 2009 10:44:19 -0800 (PST)
Message-ID: <4B0AD7FE.5000404@codemonkey.ws>
Date: Mon, 23 Nov 2009 12:44:14 -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>	<4B0A87B2.1030507@codemonkey.ws>
	<m3vdh1wd0n.fsf@neno.neno>	<4B0AA0F3.6070205@codemonkey.ws>
	<m3y6lxqkpv.fsf@neno.neno>	<4B0ABBD4.9030401@codemonkey.ws>
	<m3zl6db11z.fsf@neno.neno>
In-Reply-To: <m3zl6db11z.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:
>> The problem here isn't migration, it's what you've decided to backport
>> into your stable branch.
>>     
>
> No. the problem is that I made a mistake in the past.  And didn't add a
> field to the state that I should.  It just happens to work without that
> field in several use cases.  But in others, it fails spectacularly.
> What to do here?
>   

Blacklist the broken version of the format.  If it's known to fail under 
normal usage, that's the only right thing to do given the mechanisms we 
possess today.

>> And from an upstream position, I would oppose implementing the pvclock
>> change in the stable branch exactly because of the problems it would
>> create with live migration.
>>     
>
> Let's say that the problem is when half of the users told you that you
> can't change it in the stable branch, and the other half told you that
> without the change, migration don't work in a reliable way :(
>   

If one user needs one behavior and another user absolute needs a 
different behavior, you provide a mechanism for a user to choose which 
policy they want.

See my proposal about configurable device blacklists.

> It does'nt matter what you do, you lose :(
>   

If we stick strictly to providing mechanisms and default policies, we 
can't lose because we always pass the blame higher in the stack :-)

Regards,

Anthony Liguroi