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
> >
next prev parent 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 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.