All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Tero Kristo <tero.kristo@linux.intel.com>,
	John Fastabend <john.fastabend@gmail.com>,
	shuah@kernel.org, tglx@linutronix.de, x86@kernel.org,
	bp@alien8.de, dave.hansen@linux.intel.com, mingo@redhat.com
Cc: ast@kernel.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org, andrii@kernel.org,
	daniel@iogearbox.net, bpf@vger.kernel.org
Subject: Re: [PATCH 2/2] selftests/bpf: Add test for bpf_rdtsc
Date: Wed, 05 Jul 2023 21:57:46 -0700	[thread overview]
Message-ID: <64a649cab3dba_b20ce2081c@john.notmuch> (raw)
In-Reply-To: <2901d37a-6b5a-9076-1423-0db95b4c12d3@linux.intel.com>

Tero Kristo wrote:
> 
> On 04/07/2023 01:00, John Fastabend wrote:
> > Tero Kristo wrote:
> >> Add selftest for bpf_rdtsc() which reads the TSC (Time Stamp Counter) on
> >> x86_64 architectures. The test reads the TSC from both userspace and the
> >> BPF program, and verifies the TSC values are in incremental order as
> >> expected. The test is automatically skipped on architectures that do not
> >> support the feature.
> >>
> >> Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com>
> >> ---
> >>   .../selftests/bpf/prog_tests/test_rdtsc.c     | 67 +++++++++++++++++++
> >>   .../testing/selftests/bpf/progs/test_rdtsc.c  | 21 ++++++
> >>   2 files changed, 88 insertions(+)
> >>   create mode 100644 tools/testing/selftests/bpf/prog_tests/test_rdtsc.c
> >>   create mode 100644 tools/testing/selftests/bpf/progs/test_rdtsc.c
> >>
> >> diff --git a/tools/testing/selftests/bpf/prog_tests/test_rdtsc.c b/tools/testing/selftests/bpf/prog_tests/test_rdtsc.c
> >> new file mode 100644
> >> index 000000000000..2b26deb5b35a
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/bpf/prog_tests/test_rdtsc.c
> >> @@ -0,0 +1,67 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/* Copyright(c) 2023 Intel Corporation */
> >> +
> >> +#include "test_progs.h"
> >> +#include "test_rdtsc.skel.h"
> >> +
> >> +#ifdef __x86_64__
> >> +
> >> +static inline u64 _rdtsc(void)
> >> +{
> >> +	u32 low, high;
> >> +
> >> +	__asm__ __volatile__("rdtscp" : "=a" (low), "=d" (high));
> > I think its ok but note this could fail if user doesn't have
> > access to rdtscp and iirc that can be restricted?
> 
> It is possible to restrict RDTSC access from userspace by enabling the 
> TSD bit in CR4 register, and it will cause the userspace process to trap 
> with general protection fault.
> 
> However, the usage of RDTSC appears to be built-in to C standard 
> libraries (probably some timer routines) and enabling the CR4 TSD makes 
> the system near unusable. Things like sshd + systemd also start 
> generating the same general protection faults if RDTSC is blocked. Also, 
> attempting to run anything at all with the BPF selftest suite causes the 
> same general protection fault; not only the rdtsc test.
> 
> I tried this with couple of setups, one system running a minimalistic 
> buildroot and another one running a fedora37 installation and the 
> results were similar.

Thanks. Good enough for me.

> 
> -Tero

  reply	other threads:[~2023-07-06  4:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-03 10:57 [PATCH 0/2] x86/BPF: Add new BPF helper call bpf_rdtsc Tero Kristo
2023-07-03 10:57 ` [PATCH 1/2] x86/tsc: " Tero Kristo
2023-07-04  4:49   ` Yonghong Song
2023-07-06 12:00     ` Tero Kristo
2023-07-06  3:02   ` Alexei Starovoitov
2023-07-06  5:16     ` John Fastabend
2023-07-06 11:59       ` Tero Kristo
2023-07-06 19:51         ` Alexei Starovoitov
2023-07-07  5:41           ` John Fastabend
2023-07-07  8:27             ` Tero Kristo
2023-07-07 14:42               ` Alexei Starovoitov
2023-08-09 11:31                 ` Tero Kristo
2023-07-03 10:57 ` [PATCH 2/2] selftests/bpf: Add test for bpf_rdtsc Tero Kristo
2023-07-03 22:00   ` John Fastabend
2023-07-04  8:55     ` Tero Kristo
2023-07-06  4:57       ` John Fastabend [this message]
2023-07-03 21:55 ` [PATCH 0/2] x86/BPF: Add new BPF helper call bpf_rdtsc John Fastabend

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64a649cab3dba_b20ce2081c@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=shuah@kernel.org \
    --cc=tero.kristo@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.