lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Jan 2017 17:36:44 +0100
From:   Vitaly Kuznetsov <>
To:     Radim Krcmar <>
Cc:, Thomas Gleixner <>,,
        Haiyang Zhang <>,
        "K. Y. Srinivasan" <>,
        John Stultz <>,
        Alex Ng <>,
        Stephen Hemminger <>,
        Olaf Hering <>,
        Richard Cochran <>
Subject: Re: [PATCH v4 2/2] hv_utils: implement Hyper-V PTP source

Radim Krcmar <> writes:

> 2017-01-19 15:16+0100, Vitaly Kuznetsov:
>> With TimeSync version 4 protocol support we started updating system time
>> continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
>> there is a time sample from the host which triggers do_settimeofday[64]().
>> While the time from the host is very accurate such adjustments may cause
>> issues:
>> - Time is jumping forward and backward, some applications may misbehave.
>> - In case an NTP server runs in parallel and uses something else for time
>>   sync (network, PTP,...) system time will never converge.
>> - Systemd starts annoying you by printing "Time has been changed" every 5
>>   seconds to the system log.
>> Instead of doing in-kernel time adjustments offload the work to an
>> NTP client by exposing TimeSync messages as a PTP device. Users may now
>> decide what they want to use as a source.
>> I tested the solution with chrony, the config was:
>>  refclock PHC /dev/ptp0 poll 3 precision 1e-9
>> The result I'm seeing is accurate enough, the time delta between the guest
>> and the host is almost always within [-10us, +10us], the in-kernel solution
>> was giving us comparable results.
>> I also tried implementing PPS device instead of PTP by using not currently
>> used Hyper-V synthetic timers (we use only one of four for clockevent) but
>> with PPS source only chrony wasn't able to give me the required accuracy,
>> the delta often more that 100us.
>> Signed-off-by: Vitaly Kuznetsov <>
>> ---
> It is a nice coincidence that KVM is working on a PTP driver as well,
>, and it uses more precise/accurate
> method of converting the host time that Hyper-V could also use.
> Hyper-V provides {host_time, ref_time} tuple, but gettime64() requires
> that you return just host_time and a new "ref_time" is then computed to
> be in the middle of two guest_time reads.
> I recommend you use getcrosststamp PTP callback, which allows you to
> provide the tuple.  Userspace can then use PTP_SYS_OFFSET_PRECISE
> ioctl.

Thanks, good suggestion,

as far as I see PTP_SYS_OFFSET_PRECISE support was just added to chrony:

I'll implement getcrosststamp() as well but I'll probably have to wait
till K. Y.'s restructuring ( lands
and do my series on top of that. We'll also be using the TSC page
clocksource (when available) to not do the unneeded vmexit.

> KVM patches also proposes to change PTP_SYS_OFFSET, so when gettime64
> callback is not implemented, the ioctl uses getcrosststamp instead,
> which would avoid code duplication and improve precision/accuracy.

It's probably still worth it to have the 'lightweight' gettime64()
implementation as going through the getcrosststamp() routine (see
get_device_system_crosststamp() which we'll probably use for Hyper-V
also -- it's not very simple) every time and throwing away half of the
result doesn't look optimal.


Powered by blists - more mailing lists