Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 2 Jun 2023 08:45:15 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Steven Noonan <steven@uplinklabs.net>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Muhammad Usama Anjum <usama.anjum@collabora.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        "Guilherme G. Piccoli" <gpiccoli@igalia.com>, kernel@collabora.com
Subject: Re: Direct rdtsc call side-effect
Message-ID: <20230602064515.GA620383@hirez.programming.kicks-ass.net>
References: <6719fb05-382c-8ec4-ccda-72798906a54b@collabora.com>
 <87mt1jeax1.ffs@tglx>
 <87h6rrdoy0.ffs@tglx>
 <L9sTQNWVFoNxz-HmzFoXBX4twp84wuAx5Mf4LcxWw9k0rTAXI32rSl7WEOr7058iN6_Nyf8fLN-Ye3sq5THHjJCKG2vQLlpnVs77kKlLFV4=@uplinklabs.net>
 <20230601203127.GY4253@hirez.programming.kicks-ass.net>
 <YveIgyZYN48CEPKlxf6r_CfVBGuON83brWVxnVJGtXW70bDprPOiAtEMeKELDJj3lVYuZm7fTDQnMIuheMN01YfqfWbCGYia0uWcWIx59oM=@uplinklabs.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <YveIgyZYN48CEPKlxf6r_CfVBGuON83brWVxnVJGtXW70bDprPOiAtEMeKELDJj3lVYuZm7fTDQnMIuheMN01YfqfWbCGYia0uWcWIx59oM=@uplinklabs.net>
Precedence: bulk

On Thu, Jun 01, 2023 at 09:41:15PM +0000, Steven Noonan wrote:
> On Thursday, June 1st, 2023 at 1:31 PM, Peter Zijlstra <peterz@infradead.=
org> wrote:
> > What about kernel based emulation? You could tie it into user_dispatch
> > and have a user_dispatch tsc offset.
> >=20
>=20
> > So regular kernel emulation simply returns the native value (keeps the
> > VDSO working for one), but then from a user_dispatch range, it returns
> > +offset.
> >=20
>=20
> > That is; how slow is the below?
>=20
> It's around 1800-1900 clock cycles on this system=20

Much more expensive than the actual instruction ofcourse, but that seems
eminently usable.

> (modified patch attached, compile fix + rdtscp support).

Right, that's what I get for writing 'patches' while falling asleep :/

> Since faulting would still make the vDSO clocks go through this path
> we'd have to be careful that whatever offsets we throw into this path
> don't affect the correctness of the other clocks.

Hence the suggested tie-in with user-dispatch; only add the offset when
the IP is from the user-dispatch range.