[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] Migration hv_time rollback

From: Vitaly Kuznetsov
Subject: Re: [BUG] Migration hv_time rollback
Date: Wed, 16 Sep 2020 13:59:43 +0200

"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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]