On 18/01/2017 16:54, Miroslav Lichvar wrote: >> Sure, I'll check if it makes sense to implement PTP_SYS_OFFSET_PRECISE for >> KVM case. > But is it really so precise that the application can safely assume > there are no errors due to asymmetric delays, etc? I think > PTP_SYS_OFFSET_PRECISE should be supported only if the accuracy of > the offset measured between the HW and system clock is not worse than > the precision of the system clock (typically few tens of nanoseconds). > > It would be good to verify the accuracy of the offset when the host > and guest clocks are synchronised to each other over PTP using two > NICs with HW timestamping. PTP_SYS_OFFSET_PRECISE works if the guest can compute its own timestamp based on the same source as the device. On bare metal you have: - the source for system clock is the TSC (with clocksource_tsc) - device provides a (time, ART) tuple You can convert ART->TSC and then ask clocksource_tsc for a system time based on the device-provided ART value. Likewise for KVM: - the source for system clock is the guest TSC (with kvmclock) - host can provide a (time, guest TSC) tuple The PTP driver can take the host-provided guest TSC, and ask kvmclock for a system time based on that TSC value. It's even simpler because there's no ART->TSC conversion involved, and it will always be precise and independent of any vmexit or interrupt delay. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
