BPF List
 help / color / mirror / Atom feed
From: Jie Meng <jmeng@fb.com>
To: KP Singh <kpsingh@kernel.org>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <andrii@kernel.org>,
	<daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next] bpf,x64: Remove unnecessary check on existence of SSE2
Date: Mon, 3 Oct 2022 20:50:36 -0700	[thread overview]
Message-ID: <YzutjPBbEYOPeEzG@fb.com> (raw)
In-Reply-To: <CACYkzJ7_ZNKsE5b9ECqf7+U9qs8E2hbx4GXvAhrnG3iVApqLjg@mail.gmail.com>

On Tue, Oct 04, 2022 at 03:04:20AM +0200, KP Singh wrote:
> On Mon, Oct 3, 2022 at 3:17 AM Jie Meng <jmeng@fb.com> wrote:
> >
> > SSE2 and hence lfence are architectural in x86-64 and no need to check
> > whether they're supported in CPU.
> 
> Why do you say this?
> 
> The Instruction set reference does mention that:
> 
> Exceptions:
> 
> #UD If CPUID.01H:EDX.SSE2[bit 26] = 0
> 
> (undefined instruction when the CPUID.SSE2 bit is unset)
> 
> and also that the CPUID feature flag is SSE2

Many x86 extensions predate x86-64. When they designed x86-64, AMD
decided to make some mandatory (and hence architectural) and SSE2 is
one of them[1]. CMOV, NOPL, PAE, NX etc. are other examples.

These extensions' CPUID flags are still set. If code is to be shared
between x86 and x86-64 one can still check CPUID, but bpf_jit_comp.c
is compiled under x86-64 only so the check is redundant.

There's an example Within kernel code too: arch/x86/lib/copy_user_64.S
uses SSE (sfence) and SSE2 (movnti) instructions and doesn't check
CPUID for their presence.

---
[1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

> >
> > Signed-off-by: Jie Meng <jmeng@fb.com>
> > ---
> >  arch/x86/net/bpf_jit_comp.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index d09c54f3d2e0..b2124521305e 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -1289,8 +1289,7 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image, u8 *rw_image
> >
> >                         /* speculation barrier */
> >                 case BPF_ST | BPF_NOSPEC:
> > -                       if (boot_cpu_has(X86_FEATURE_XMM2))
> > -                               EMIT_LFENCE();
> > +                       EMIT_LFENCE();
> >                         break;
> >
> >                         /* ST: *(u8*)(dst_reg + off) = imm */
> > --
> > 2.30.2
> >

  reply	other threads:[~2022-10-04  3:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03  1:17 [PATCH bpf-next] bpf,x64: Remove unnecessary check on existence of SSE2 Jie Meng
2022-10-04  1:04 ` KP Singh
2022-10-04  3:50   ` Jie Meng [this message]
2022-10-05  0:30     ` KP Singh
2022-10-05 17:00       ` [PATCH bpf-next v2] " Jie Meng
2022-10-06  0:58         ` KP Singh
2022-10-07 14:30         ` patchwork-bot+netdevbpf

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=YzutjPBbEYOPeEzG@fb.com \
    --to=jmeng@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kpsingh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox