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

[Wen Gu <guwen@linux.alibaba.com>]

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.