Re: [BUG] Migration hv_time rollback

[Vitaly Kuznetsov <vkuznets@redhat.com>]

"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:

> cc'ing in Vitaly who knows about the hv stuff.
>

cc'ing Marcelo who knows about clocksources :-)

> * Antoine Damhet (antoine.damhet@blade-group.com) wrote:
>> Hi,
>> 
>> We are experiencing timestamp rollbacks during live-migration of
>> Windows 10 guests

Are you migrating to the same hardware (with the same TSC frequency)? Is
TSC used as the clocksource on the host?

>>  with the following qemu configuration (linux 5.4.46
>> and qemu master):
>> ```
>> $ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...]
>> ```

Out of pure curiosity, what's the purpose of doing 'kvm=off'? Windows is
not going to check for KVM identification anyway so we pretend we're
Hyper-V. 

Also, have you tried adding more Hyper-V enlightenments? 

>
> How big a jump are you seeing, and how did you notice it in the guest?
>
> Dave
>
>> I have tracked the bug to the fact that `kvmclock` is not exposed and
>> disabled from qemu PoV but is in fact used by `hv-time` (in KVM).
>> 
>> I think we should enable the `kvmclock` (qemu device) if `hv-time` is
>> present and add Hyper-V support for the `kvmclock_current_nsec`
>> function.

AFAICT kvmclock_current_nsec() checks whether kvmclock was enabled by
the guest:

   if (!(env->system_time_msr & 1ULL)) {
        /* KVM clock not active */
        return 0;
    }

and this is (and way) always false for Windows guests.

>> 
>> I'm asking for advice because I am unsure this is the _right_ approach
>> and how to keep migration compatibility between qemu versions.
>> 
>> Thank you all,
>> 
>> -- 
>> Antoine 'xdbob' Damhet

-- 
Vitaly