From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6586243DA4C for ; Fri, 22 May 2026 15:28:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779463691; cv=none; b=I/TOtwq1jtQtN5vocgnF6RaiwnMsezAdcepSbZD6qdMfVotZvU3OSNQHTHoRjPmjdsUxm3/7rkIdP9Rv8QD/Wy46TSxD1FjImCaBcwpCyfrNQeyz9iHpZyTl8BVrpj+1JTamu9DBIH/8A8Qt1uMECAyUx5+w1wLwpSCRcv60KR4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779463691; c=relaxed/simple; bh=GOL/IHgrx9ZLv9BY6ruVhRZPQ0Oc4u1pC1HPOYK5saY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hQ2qL3gPC8zIzGyANaHHgpiyy206UFi+cEL3JnG4zGfyJh9vP+btRld+MkbHLDlB4VxasuEevllXHBLn70gJtPhsDetNCimw8/jU8hnmKCi260iPRIVYEjQk7Sw0T1Ikme69IhFoF0+7UXqRuuzhsCBlF/HD+ZP8TJD4GXV37eo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EjaU2ZNM; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EjaU2ZNM" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id 68BA21F000E9; Fri, 22 May 2026 15:28:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779463689; bh=jx/AyhZLBYlG76PXnUuQu4ewau5KvANoMK4CMNEWI94=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=EjaU2ZNMtVaEh8TpFSTMJAY5v8wsctR2WtnzCBZqGXNd9hp417UPdtVW0rzZLvP/L sweq9nTcknEa1YCnvZFYtp4GbzdoYC9kIHBI4fjVxZVBAbVloc8mAfg63lmPG6tLOI kMs+iqzfP40DoLrhTO/1PTfL8JTKOkEr+BQYUWBDdun8afp9TjliTHi19u1OgqoJWf FcUoo4pO3EDNvgFxI62ewR9RT3c5UmIX/iEEXfTlRRscPOrSVOlCpzq/HLDXOQkjT5 +1sgz7gE+Alfo1V0kDarjVf70S0vj/gqm7UJN+pE1UeVdH7Sy6SF1Cwda3f7OUnti4 13EKHmMTQwNHQ== From: Thomas Gleixner To: David Woodhouse , Miroslav Lichvar Cc: Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Arnd Bergmann , Julien Ridoux , Ryan Luu , linux-kernel@vger.kernel.org, Marcelo Tosatti Subject: Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock In-Reply-To: <00609fa255442648e11e2b5596a3b80a29edcfc8.camel@infradead.org> References: <20260517220326.4625-1-dwmw2@infradead.org> <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@infradead.org> <87o6i8vcni.ffs@tglx> <6c7137748ccea288fdf55e7c2e24817ccc1673ef.camel@infradead.org> <874ijzvpl8.ffs@tglx> <00609fa255442648e11e2b5596a3b80a29edcfc8.camel@infradead.org> Date: Fri, 22 May 2026 17:28:05 +0200 Message-ID: <87v7cftqey.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, May 22 2026 at 11:01, David Woodhouse wrote: > On Fri, 2026-05-22 at 10:02 +0200, Thomas Gleixner wrote: > Obviously. But to take a PoC and then do that thought and turn it into > something we can use, it still needs a Co-developed-by: and thus a > Signed-off-by: if you would be so kind. git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/ptp/timekeeping is the work in progress state as of now. I'm not going to touch it in the next days and it's still in a rough uncompiled state. It lacks quite some change logs and the last patch needs to be split up. I'll go and have a look next week so that I can rethink the approach with a clear mind. > Heh, the 'made up world' of which you speak is KVM. The older KVM PTP > drivers get a CSID_X86_TSC or CSID_ARM_ARCH_COUNTER value too. > > And they *use* it... and wait, get_device_system_crosststamp() already > *does* require the device to generate a system_counterval_t, so your > nightmare world where driver authors might pull it out of their > posterior *already* exists, doesn't it? It exists. Because get_device_system_crosststamp() does _NOT_ propagate the counter values after converting them to actual TSC values. The half baked snipped I provided you earlier does exactly that (but wrong). The version in the git branch should be halfways functional. > And we have things like stmmac which already populate it using > CSID_X86_ART. It does not populate back into PTP land. That's a get_device_system_crosststamp() internal handshake where the driver callback provides the PTM time stamp and tells the core which clock source it is based on. The core converts it to the system clocksource cycles, e.g. ART to TSC, and then calculates MONO_RAW and REALTIME from it, optionally with an extra snapshot that allows historical interpolation for devices where the timestamp retrieval takes ages. > So at least for PTP_SYS_OFFSET_PRECISE, isn't Arthur's patch literally > only exporting the same counter values that the driver *already* > creates? I'm not quite sure why we have all these histrionics about > drivers not being able to create those reliably? The driver reads it from the hardware but it does not know how to convert them back to TSC or anything else. For the driver it's an opaque piece of data which it read out of a register or got retrieved through a firmware query. > Yes, there's plenty to improve as discussed, and we should probably > have get_device_system_crosststamp() copy the values from the > system_counterval on its local stack into the system_device_crosststamp > rather than asking the driver to pass it back through separate fields > in the attributes. See the original snippet and the git tree how that is done by extending the cross time stamp structure and storing all the information there, which is what PTP hands in: system_cross_timestamp sct; ptp->info->getcrosstimestamp(..., &sct) driver_getcrosstimestamp(...., *sct) { get_device_system_crosststamp(callback, context, ..., sct) { system_counterval_t scv; ktime_t device_time; do { ... callback(&device_time, &scv, context) { read_snapshot(&pch_time, &ptm_time); *device_time = munge(pch_time); scv->cycles = ptm_time; scv->cs_id = ART; } .... cs_cycles = convert_ptm_to_cs(scv.cycles, scv.cs_id); real = timekeeping_convert_to_real(cs_cycles); raw = timekeeping_convert_to_raw(cs_cycles); } while (seq_retry()); sct->device = device_time; sct->real = real; sct->raw = raw; } So the new parts are that system_cross_timestamp gains a system_counter_val and get_device_system_crosststamp() fills that in: sct->counter.cycles = cs_cycles; sct->counter.cs_id = csid; On X86 you get the TSC cycles (derived from ART) and CSID_X86_TSC. That goes all the way back to the PTP layer. Which means magically _all_ existing users of get_device_system_crosststamp() will provide that data out of the box. The existing PRECISE usecase will just ignore sct.counter. Your new stuff can use it and fill in the related attributes in the user space attr struct. This raises an interesting question. Must any of the existing PTM using drivers mplement that new extended getcrosstimestampattr() callback, in order to expose the cycles/csid in attr or can you fallback to the existing callback and have the rest of the fields 0? Same question arises if you change the pre/post timestamp helpers to utilize ktime_get_snapshot_id(). All existing drivers which use them will then automatically retrieve cs_cycles/cs_id. The other change I did to get_device_system_crosststamp() is to let the PTP core hand in the clock ID, so it can retrieve either REALTIME or AUX clocks, which enables the whole AUX world to utilize PTM too once the PTP IOCTL is updated accordingly. Can you please make the new PTP_SYS_OFFSET_PRECISE_ATTRS and PTP_SYS_OFFSET_EXTENDED_ATTRS so that user space can convey the CLOCK ID, like it does today with PTP_SYS_OFFSET_EXTENDED? Thanks, tglx