From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: Bjorn Topel <bjorn.topel@gmail.com>,
daniel@iogearbox.net, ast@kernel.org, zlim.lnx@gmail.com,
catalin.marinas@arm.com, will@kernel.org, kafai@fb.com,
songliubraving@fb.com, yhs@fb.com, andriin@fb.com,
shuah@kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
clang-built-linux@googlegroups.com, kernel-team@android.com
Subject: Re: [PATCH 4/4] arm64: bpf: Elide some moves to a0 after calls
Date: Mon, 10 Feb 2020 16:15:27 -0800 [thread overview]
Message-ID: <20200211001526.xbfwdnpjqrg3ed6q@ast-mbp> (raw)
In-Reply-To: <20200128021145.36774-5-palmerdabbelt@google.com>
On Mon, Jan 27, 2020 at 06:11:45PM -0800, Palmer Dabbelt wrote:
>
> + /* Handle BPF_REG_0, which may be in the wrong place because the ARM64
> + * ABI doesn't match the BPF ABI for function calls. */
> + if (ctx->reg0_in_reg1) {
> + /* If we're writing BPF_REG_0 then we don't need to do any
> + * extra work to get the registers back in their correct
> + * locations. */
> + if (insn->dst_reg == BPF_REG_0)
> + ctx->reg0_in_reg1 = false;
> +
> + /* If we're writing to BPF_REG_1 then we need to save BPF_REG_0
> + * into the correct location if it's still alive, as otherwise
> + * it will be clobbered. */
> + if (insn->dst_reg == BPF_REG_1) {
> + if (!dead_register(ctx, off + 1, BPF_REG_0))
> + emit(A64_MOV(1, A64_R(7), A64_R(0)), ctx);
> + ctx->reg0_in_reg1 = false;
> + }
> + }
I'm not sure this is correct, since it processes insns as a linear code, but
there could be jumps in the middle. The logic should be following the control
flow of the program. The verifier is a better place to do such analysis.
I don't see how JITs can do it on their own.
WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: songliubraving@fb.com, andriin@fb.com, daniel@iogearbox.net,
kernel-team@android.com, Bjorn Topel <bjorn.topel@gmail.com>,
shuah@kernel.org, ast@kernel.org, linux-kernel@vger.kernel.org,
clang-built-linux@googlegroups.com, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, catalin.marinas@arm.com,
zlim.lnx@gmail.com, yhs@fb.com, bpf@vger.kernel.org,
will@kernel.org, kafai@fb.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/4] arm64: bpf: Elide some moves to a0 after calls
Date: Mon, 10 Feb 2020 16:15:27 -0800 [thread overview]
Message-ID: <20200211001526.xbfwdnpjqrg3ed6q@ast-mbp> (raw)
In-Reply-To: <20200128021145.36774-5-palmerdabbelt@google.com>
On Mon, Jan 27, 2020 at 06:11:45PM -0800, Palmer Dabbelt wrote:
>
> + /* Handle BPF_REG_0, which may be in the wrong place because the ARM64
> + * ABI doesn't match the BPF ABI for function calls. */
> + if (ctx->reg0_in_reg1) {
> + /* If we're writing BPF_REG_0 then we don't need to do any
> + * extra work to get the registers back in their correct
> + * locations. */
> + if (insn->dst_reg == BPF_REG_0)
> + ctx->reg0_in_reg1 = false;
> +
> + /* If we're writing to BPF_REG_1 then we need to save BPF_REG_0
> + * into the correct location if it's still alive, as otherwise
> + * it will be clobbered. */
> + if (insn->dst_reg == BPF_REG_1) {
> + if (!dead_register(ctx, off + 1, BPF_REG_0))
> + emit(A64_MOV(1, A64_R(7), A64_R(0)), ctx);
> + ctx->reg0_in_reg1 = false;
> + }
> + }
I'm not sure this is correct, since it processes insns as a linear code, but
there could be jumps in the middle. The logic should be following the control
flow of the program. The verifier is a better place to do such analysis.
I don't see how JITs can do it on their own.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-11 0:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-28 2:11 arm64: bpf: Elide some moves to a0 after calls Palmer Dabbelt
2020-01-28 2:11 ` Palmer Dabbelt
2020-01-28 2:11 ` [PATCH 1/4] selftests/bpf: Elide a check for LLVM versions that can't compile it Palmer Dabbelt
2020-01-28 2:11 ` Palmer Dabbelt
2020-02-11 18:20 ` Nick Desaulniers
2020-02-11 18:20 ` Nick Desaulniers
2020-01-28 2:11 ` [PATCH 2/4] arm64: bpf: Convert bpf2a64 to a function Palmer Dabbelt
2020-01-28 2:11 ` Palmer Dabbelt
2020-01-28 2:11 ` [PATCH 3/4] arm64: bpf: Split the read and write halves of dst Palmer Dabbelt
2020-01-28 2:11 ` Palmer Dabbelt
2020-01-28 2:11 ` [PATCH 4/4] arm64: bpf: Elide some moves to a0 after calls Palmer Dabbelt
2020-01-28 2:11 ` Palmer Dabbelt
2020-02-04 19:13 ` Björn Töpel
2020-02-04 19:13 ` Björn Töpel
2020-02-11 0:15 ` Alexei Starovoitov [this message]
2020-02-11 0:15 ` Alexei Starovoitov
2020-02-04 19:30 ` Björn Töpel
2020-02-04 19:30 ` Björn Töpel
2020-02-04 20:33 ` John Fastabend
2020-02-04 20:33 ` John Fastabend
2020-02-18 19:28 ` Palmer Dabbelt
2020-02-18 19:28 ` Palmer Dabbelt
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=20200211001526.xbfwdnpjqrg3ed6q@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=clang-built-linux@googlegroups.com \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=palmerdabbelt@google.com \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=will@kernel.org \
--cc=yhs@fb.com \
--cc=zlim.lnx@gmail.com \
/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.