linux-kernel - Re: [PATCH 00/21] ntp: Rework to prepare support of indenpendent PTP clocks

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: <87bk0rj1a1.fsf@somnus>
Date: Fri, 13 Sep 2024 12:28:22 +0200
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Miroslav Lichvar <mlichvar@...hat.com>
Cc: John Stultz <jstultz@...gle.com>, Frederic Weisbecker
 <frederic@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org, Richard Cochran
 <richardcochran@...il.com>, Christopher S Hall
 <christopher.s.hall@...el.com>
Subject: Re: [PATCH 00/21] ntp: Rework to prepare support of indenpendent
 PTP clocks

Miroslav Lichvar <mlichvar@...hat.com> writes:

> On Wed, Sep 11, 2024 at 03:17:36PM +0200, Anna-Maria Behnsen wrote:
>> This problem can be solved by emulating clock_gettime() via the system
>> clock source e.g. TSC on x86. Such emulation requires:
>> 
>> 1. timekeeping mechanism similar to the existing system timekeeping
>> 2. clock steering equivalent to NTP/adjtimex()
>
> I'm trying to understand what independent PTP clocks means here. Is
> the goal to provide virtual PTP clocks running on top of the system
> clocksource (e.g. TSC) similarly to what is currently done for
> physical PTP clocks by writing to /sys/class/ptp/ptp*/n_vclocks,
> expecting the virtual clocks to be synchronized by applications like
> phc2sys?
>
> Or is this more about speeding up the reading of the PHC, where the
> kernel itself would be tracking the offset using one of the PTP
> driver's PTP_SYS_OFFSET operations and emulating a fast-reading PHC?

That's one aspect.

The independant PTP clocks are PTP clocks which are not synchronized
with CLOCK_TAI. They are "standalone". They are used in automation and
automotive setups. They have a grand clock master which is not
synchronized to anything. There are also requirements for redundant
networks where the clocks are not allowed to be synchronized between the
networks to prevent common cause failures.

These clocks are used for TSN and both applications and the network
stack needs to be able to read the time. Going through the file
decriptor based interfaces is slow and not possible in the kernel.

The goal is to provide infrastructure which allows these clocks to be
read via kernel interfaces and clock_gettime(PTPID) by emulating the
clock via the system clocksource (e.g. TSC).

That means they need timekeeping and steering infrastructure, to keep
them in sync with the PHC. It's the identical mechanism to what system
timekeeping and NTP do for the system clocks.

So instead of creating duplicate infrastructure, this aims to reuse the
existing one.

Hope this helps to make it more clear.

Thanks,

        Anna-Maria