On Thu, 2026-05-14 at 22:58 +0000, Harshitha Ramamurthy wrote:

+static bool
+gve_can_use_system_ts_from_device(enum clocksource_ids system_clock_source,
+				  clockid_t clockid)
+{
+	if (clockid != CLOCK_REALTIME && clockid != CLOCK_MONOTONIC_RAW)
+		return false;
+
+	/* If the system clock source matches the system clock
+	 * returned by the AdminQ command, we can use the system
+	 * timestamps returned by the device, otherwise we have to
+	 * fall back to sampling system time from the host which
+	 * is less accurate.
+	 */
+	if (IS_ENABLED(CONFIG_X86))
+		return system_clock_source == CSID_X86_TSC;
+	else if (IS_ENABLED(CONFIG_ARM64))
+		return system_clock_source == CSID_ARM_ARCH_COUNTER;
+
+	return false;

Strictly, you could manage to convert to CSID_X86_KVM_CLK here too. The
x86 kvm_arch_ptp_get_crosststamp() for ptp_kvm does so unconditionally.

For ptp_vmclock we support both; we do the conversion only if the cs_id
in the snapshot *is* the KVM clock, which seemed a bit more reasonable.

And here you add a third variant which *only* copes with CSID_X86_TSC,
to complete the set of possibilities :)

With PTM and the various virt enlightenments, there are an increasing
number of "PTP" clocks which literally *just* tell us a cycle count at
the moment of the corresponding reading, and we don't need the ABA
sandwich of local clock readings around it any more.

I've got another one waiting in the wings which will literally just
latch the counter value when a PPS signal comes in, too.

It might be good to harmonise the way we convert to KVM clock if we're
going to support that (although I'll accept an argument that any guest
which chooses to use the KVM clock doesn't *deserve* to have accurate
timekeeping).

I'd also like consensus on exposing it to userspace. I think Thomas is
going to suggest that we should always convert to MONOTONIC_RAW, but
what I asked Arthur to do in 
https://lore.kernel.org/all/20260515164033.6403-1-akiyano@amazon.com/ (local)
exposes the raw counter values instead.

From the dedicating hosting point of view, we *only* care about the
counter, and absolutely DGAF about the host's timekeeping. Migrating
KVM guests requires getting the guest TSC right (in terms of scaling
factors and offset from the host TSC), and feeding accurate time to
guests is done in terms of the guest TSC to realtime relationship.
So our ideal state is that we discipline the TSC against real time in
userspace, and enabling those PHC drivers to *give* us the raw cycle
counts that they actually measured seemed best.

Could we do that all on MONOTONIC_RAW, if Thomas insists? Maybe...
although I like the model of disciplining one *specific* counter, and
then telling the kernel about *that* counter. If the kernel for some
reason has randomly switched to the HPET then the kernel is free to
ignore what we're telling it about the TSC.