Re: [patch 15/38] ptp: ptp_vmclock: Replace get_cycles() usage

"Arnd Bergmann" <[email protected]> Mon, 13 Apr 2026 21:30:11 +0200
Newsgroups org.kernel.vger.linux-hams,dev.linux.lists.iommu,dev.linux.lists.loongarch,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-alpha,org.kernel.vger.linux-crypto,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fbdev,org.kernel.vger.linux-kernel,org.kernel.vger.linux-m68k,org.kernel.vger.linux-openrisc,org.kernel.vger.linux-parisc,org.kernel.vger.linux-s390,org.kernel.vger.linux-wireless,org.kernel.vger.netdev,org.kernel.vger.sparclinux,org.kvack.linux-mm,org.ozlabs.lists.linuxppc-dev
Message-ID <[email protected]>
On Mon, Apr 13, 2026, at 17:33, David Woodhouse wrote:
> On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
>
> ... depend on TSC_RELIABLE=C2=B9, since if the guest doesn't believe t=
hat it
> is, then the guest shouldn't be trying to use it as the basis for
> precise timing.
>
> =C2=B9 (Or... one of the other zoo of TSC flags for the gradually redu=
cing
> brokenness over the years...)

It looks like this is sufficiently handled in the caller:

static int vmclock_get_crosststamp(struct vmclock_state *st,
                                   struct ptp_system_timestamp *sts,
                                   struct system_counterval_t *system_co=
unter,
                                   struct timespec64 *tspec)
{
....
#ifdef CONFIG_X86
        /*
         * We'd expect the hypervisor to know this and to report the clo=
ck
         * status as VMCLOCK_STATUS_UNRELIABLE. But be paranoid.
         */
        if (check_tsc_unstable())
                return -EINVAL;
#endif

With 486 and ELAN out of the way, Winchip6 seems to be the only
one without X86_FEATURE_TSC, so I think the next logical step would
be to turn off Winchip6 as well and remove all X86_FEATURE_TSC
and CONFIG_X86_TSC checks.

      Arnd