From: Jakub Kicinski Date: Wed, 20 May 2026 01:17:30 +0000 (-0700) Subject: Merge branch 'gve-add-support-for-ptp-gettimex64' X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9587ed8137fb83d93f84b858337412f4500b21e9;p=thirdparty%2Fkernel%2Flinux.git Merge branch 'gve-add-support-for-ptp-gettimex64' Jordan Rhee says: ==================== gve: add support for PTP gettimex64 This patch series adds support to obtain near-simultaneous NIC and system timestamps with gettimex64. This enables daemons like chrony and phc2sys to synchronize the system clock to the NIC clock. GVE does not have direct register access to the NIC hardware clock, so it must issue an AdminQ command to read the NIC clock. Two paths for obtaining a cross-timestamp are implemented: a precise path using system counter values sampled by the device, and a fallback path using system counter values sampled in the driver using ptp_read_system_prets()/postts(). To use the precise path, the current system clocksource must match the units returned by the device, which on x86 is X86_TSC and on ARM64 is ARM_ARCH_COUNTER. The clockid requested for the cross-timestamp must be either CLOCK_REALTIME or CLOCK_MONOTONIC_RAW. These conditions hold by default on GCP VMs using Chrony, so we expect the precise path to be used the vast majority of the time. If the system clocksource is changed to kvm-clock, it activates the fallback path. Ethtool counters have been added to count how many times each path is used. The uncertainty window in the precise path is typically around 1-2us, while in the fallback path is around 60-80us. This table shows a comparison in chrony tracking statistics between the precise path and fallback path. The RMS offset is nearly 4 orders of magnitude smaller in the precise path. | | Fallback Path | Precise path | | --------------- | --------------------- | ------------------------ | | System time | 0.000000005 s slow | 0.000000001 s fast | | Last offset | +0.000005606 seconds | +0.000000001 seconds | | RMS offset | 0.000009020 seconds | 0.000000002 seconds | | Frequency | 4.115 ppm fast | 0.362 ppm fast | | Residual freq | +2.515 ppm | +0.000 ppm | | Skew | 18.480 ppm | 0.001 ppm | | Root delay | 0.000000001 seconds | 0.000000001 seconds | | Root dispersion | 0.000081905 seconds | 0.000001169 seconds | | Update interval | 0.5 seconds | 0.5 seconds | | Leap status | Normal | Normal | The first two patches pave the way for the PTP implementation by quieting excessive logging and refactoring an existing routine for thread safety. ==================== Link: https://patch.msgid.link/20260514225842.110706-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski --- 9587ed8137fb83d93f84b858337412f4500b21e9