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/[email protected]/ 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.
