[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

["Michael S. Tsirkin" <mst@redhat.com>]

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