qemu-devel
[Top][All Lists]
Advanced

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

Re: [BUG] Migration hv_time rollback


From: Antoine Damhet
Subject: Re: [BUG] Migration hv_time rollback
Date: Wed, 16 Sep 2020 14:14:09 +0200

On Wed, Sep 16, 2020 at 01:59:43PM +0200, Vitaly Kuznetsov wrote:
> "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?

Yes we are migrating to the exact same hardware. And yes TSC is used as
a clocksource in the host (but the bug is still happening with `hpet` as
a clocksource).

> 
> >>  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. 

Some softwares explicitly checks for the presence of KVM and then crash
if they find it in CPUID :/

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

Yes, I published a stripped-down command-line for a minimal reproducer
but even `hv-frequencies` and `hv-reenlightenment` don't help.

> 
> >
> > 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.

Hooo, I missed this piece. When is `clock_is_reliable` expected to be
false ? Because if it is I still think we should be able to query at
least `HV_X64_MSR_REFERENCE_TSC`

> 
> >> 
> >> 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
> 

-- 
Antoine 'xdbob' Damhet

Attachment: signature.asc
Description: PGP signature


reply via email to

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