netdev - Re: [RFC] Defining a home/maintenance model for non-NIC PHC devices using the /dev/ptpX API

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <5f3bed2e-b174-4a89-9cde-5c43f9b93702@linux.alibaba.com>
Date: Wed, 14 Jan 2026 17:06:35 +0800
From: Wen Gu <guwen@...ux.alibaba.com>
To: David Woodhouse <dwmw2@...radead.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Richard Cochran <richardcochran@...il.com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>
Cc: Jakub Kicinski <kuba@...nel.org>, Dust Li <dust.li@...ux.alibaba.com>,
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 virtualization@...ts.linux.dev, Nick Shi <nick.shi@...adcom.com>,
 Sven Schnelle <svens@...ux.ibm.com>, Paolo Abeni <pabeni@...hat.com>,
 linux-clk@...r.kernel.org
Subject: Re: [RFC] Defining a home/maintenance model for non-NIC PHC devices
 using the /dev/ptpX API



On 2026/1/12 16:04, David Woodhouse wrote:
> 
> Thanks for starting this discussion.
> 
> I agree that the existing 'pure' PHC drivers should keep the option of
> presenting themselves as PTP devices to userspace. I would probably
> have suggested moving them out of drivers/ptp/… to somewhere else under
> drivers/ entirely, but that's bikeshedding.
> 

Thanks for the feedback. The directory and naming will be improved.

> I do think we have slightly different requirements for the pure PHCs
> too though, particularly the virt-focused ones. It would be good if we
> could set a guest's clock from them at startup, and the primary focus
> of them is for calibrating the guest's CLOCK_REALTIME. Which means we
> do actually care about consuming UTC offset and leap second information
> from them, not just TAI.
> 

Yes, we have slightly different requirements. The original motivation
for Alibaba CIPU PTP clock was to provide usable PTP clocks for cloud
services that require precise timing. Guest/VM time synchronization
was not the primary target.

However, I think the idea you mentioned is valuable for virtualization
scenario, eliminating the need for a userspace daemon and directly
calibrating the guest's CLOCK_REALTIME.

> I'd also like microvms to be able to consume time directly, especially
> from vmclock, without needing a full-blown NTP-capable userspace. I've
> experimented with simulating 1PPS support to feed into the kernel's
> timekeeping, although I don't think that's the best answer:
> https://lore.kernel.org/all/87cb97d5a26d0f4909d2ba2545c4b43281109470.camel@infradead.org/
> 
> We could do with harmonising the workarounds for kvmclock too. I made
> sure the vmclock driver reports its timestamp pairs in terms of either
> CSID_X86_TSC or CSID_X86_KVM_CLK as appropriate, but ptp_kvm *only*
> uses kvmclock (which is daft, since anyone who cares about accurate
> time will be using tsc). I was thinking that interface of the pure PHC
> drivers could be really simple, and our new infrastructure could
> provide the ptp_clock_info glue, including the kvmclock conversion if
> needed. And *also* hook them in for setting the clock at startup, and
> even calibrating CLOCK_REALTIME.

I expect the drivers covered by "pure PHC" will be diverse, covering
a range of non-network/IEEE 1588-oriented implementations.
PHC drivers for virtualization scenarios could be one subset. Further
virtualization-specific optimizations can be considered as follow-up
work with the virtualization and timekeeping experts.

Regards.