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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox