On Fri, Aug 10, 2018 at 09:15:51AM +0200, Paolo Bonzini wrote:
> On 09/08/2018 16:52, Marcelo Tosatti wrote:
> > Commit 0bc48bea36d1 ("KVM: x86: update master clock before computing kvmclock_offset")
> > switches the order of operations to avoid the conversion
> >
> > TSC (without frequency correction) ->
> > system_timestamp (with frequency correction),
> >
> > which might cause a time jump.
> >
> > However, it leaves any other masterclock update unsafe, which includes,
> > at the moment:
> >
> > * HV_X64_MSR_REFERENCE_TSC MSR write.
> > * TSC writes.
> > * Host suspend/resume.
> >
> > Avoid the time jump issue by using frequency uncorrected
> > CLOCK_MONOTONIC_RAW clock.
> >
> > Its the guests time keeping software responsability
> > to track and correct a reference clock such as UTC.
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
>
> What happens across migration?
>
> Paolo
You mean between
frequency corrected host -> frequency uncorrected host
And vice-versa?
I'll check NTP's/Chrony's behaviour and let you know.
Thanks
