From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCveu-0007ad-JY
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:42:20 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCvep-0007aB-NR
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:42:19 -0500
Received: from [199.232.76.173] (port=59664 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCvep-0007a8-JR
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:42:15 -0500
Received: from mx1.redhat.com ([209.132.183.28]:32078)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mst@redhat.com>) id 1NCvep-0007K8-5B
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:42:15 -0500
Date: Tue, 24 Nov 2009 15:39:36 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20091124133936.GG2405@redhat.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B0AA0F3.6070205@codemonkey.ws>
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Juan Quintela <quintela@trasno.org>, Gleb Natapov <gleb@redhat.com>, qemu-devel@nongnu.org

On Mon, Nov 23, 2009 at 08:49:23AM -0600, Anthony Liguori wrote:
> Juan Quintela wrote:
>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>>   
>>> Juan Quintela wrote:
>>>     
>>
>>   
>>> 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.
>>>     
>>
>> The problem that we are having in RHEL just now is that there are two
>> new fields to make pvclock/kvmclock more exact (this is qemu-kvm tree):
>>
>>         /* KVM pvclock msr */
>>         VMSTATE_UINT64_V(system_time_msr, CPUState, 12),
>>         VMSTATE_UINT64_V(wall_clock_msr, CPUState, 12),
>>
>> Before we added that values to the state, we used whatever time the host
>> were using for that values (yes, we had drift).
>>
>> But if we don't send that two values, we are not worse that we were
>> before adding that to the state.
>>   
>
> But the effect is that after you migrate, you change behavior.  In this  
> case, you migrate a guest that isn't drifting and then after migration,  
> you start drifting.

Why is this much better than the other way around?
Migrating from old qemu to new one, we stop drifting.

Users and applications that are sensitive to time drift simply can't use
qemu versions which have time drift, but not all of them are.  There's
no reason to try and prevent everyone from doing this by breaking
new->old migration.


-- 
MST