Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [patch 11/11] x66/vdso: Add CLOCK_TAI support
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20180914125119.081037164@linutronix.de>
Date:   Fri, 14 Sep 2018 07:04:02 -0700
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Andy Lutomirski <luto@kernel.org>, x86@kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Matt Rickard <matt@softrans.com.au>,
        Stephen Boyd <sboyd@kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        Florian Weimer <fweimer@redhat.com>,
        "K. Y. Srinivasan" <kys@microsoft.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        devel@linuxdriverproject.org,
        virtualization@lists.linux-foundation.org,
        Paolo Bonzini <pbonzini@redhat.com>,
        Arnd Bergmann <arnd@arndb.de>, Juergen Gross <jgross@suse.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABB53D42-2A06-41B9-8A8C-40B39CD0289D@amacapital.net>
References: <20180914125006.349747096@linutronix.de> <20180914125119.081037164@linutronix.de>
To:     Thomas Gleixner <tglx@linutronix.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>=20
> With the storage array in place it's now trivial to support CLOCK_TAI in
> the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use=

> of the fact that:
>=20
> - CLOCK ids are set in stone
> - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so
>   the array slot 3 is unused
> - CLOCK_TAI is id 11 which results in 3 when masked with 0x3
>=20
> Add the mask to the basetime array lookup and set up the CLOCK_TAI base
> time in update_vsyscall().

That=E2=80=99s... horrible. In an amazing way. Can you add BUILD_BUG_ON some=
where to assert that this actually works?

>=20
> The performance impact of the mask operation is within the noise.
>=20
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> arch/x86/entry/vdso/vclock_gettime.c    |    2 +-
> arch/x86/entry/vsyscall/vsyscall_gtod.c |    4 ++++
> arch/x86/include/asm/vgtod.h            |    6 +++++-
> 3 files changed, 10 insertions(+), 2 deletions(-)
>=20
> --- a/arch/x86/entry/vdso/vclock_gettime.c
> +++ b/arch/x86/entry/vdso/vclock_gettime.c
> @@ -140,7 +140,7 @@ notrace static inline u64 vgetcyc(int mo
>=20
> notrace static int do_hres(clockid_t clk, struct timespec *ts)
> {
> -    struct vgtod_ts *base =3D &gtod->basetime[clk];
> +    struct vgtod_ts *base =3D &gtod->basetime[clk & VGTOD_HRES_MASK];
>    u64 cycles, last, ns;
>    unsigned int seq;
>=20
> --- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
> +++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
> @@ -51,6 +51,10 @@ void update_vsyscall(struct timekeeper *
>    base->sec =3D tk->xtime_sec;
>    base->nsec =3D tk->tkr_mono.xtime_nsec;
>=20
> +    base =3D &vdata->basetime[VGTOD_TAI];
> +    base->sec =3D tk->xtime_sec + (s64)tk->tai_offset;
> +    base->nsec =3D tk->tkr_mono.xtime_nsec;
> +
>    base =3D &vdata->basetime[CLOCK_MONOTONIC];
>    base->sec =3D tk->xtime_sec + tk->wall_to_monotonic.tv_sec;
>    nsec =3D tk->tkr_mono.xtime_nsec;
> --- a/arch/x86/include/asm/vgtod.h
> +++ b/arch/x86/include/asm/vgtod.h
> @@ -19,9 +19,13 @@ struct vgtod_ts {
> };
>=20
> #define VGTOD_BASES    (CLOCK_MONOTONIC_COARSE + 1)
> -#define VGTOD_HRES    (BIT(CLOCK_REALTIME) | BIT(CLOCK_MONOTONIC))
> +#define VGTOD_HRES    (BIT(CLOCK_REALTIME) | BIT(CLOCK_MONOTONIC) | BIT(C=
LOCK_TAI))
> #define VGTOD_COARSE    (BIT(CLOCK_REALTIME_COARSE) | BIT(CLOCK_MONOTONIC_=
COARSE))
>=20
> +/* Abuse CLOCK_THREAD_CPUTIME_ID for VGTOD CLOCK TAI */
> +#define VGTOD_HRES_MASK    0x3
> +#define VGTOD_TAI    (CLOCK_TAI & VGTOD_HRES_MASK)
> +
> /*
>  * vsyscall_gtod_data will be accessed by 32 and 64 bit code at the same t=
ime
>  * so be carefull by modifying this structure.
>=20
>=20