[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba3656eb-500b-9f14-1c97-d27868f1c3e6@fb.com>
Date: Wed, 28 Jul 2021 16:52:08 -0700
From: Yonghong Song <yhs@...com>
To: Johan Almbladh <johan.almbladh@...finetworks.com>,
<ast@...nel.org>, <daniel@...earbox.net>, <andrii@...nel.org>
CC: <kafai@...com>, <songliubraving@...com>,
<john.fastabend@...il.com>, <kpsingh@...nel.org>,
<Tony.Ambardar@...il.com>, <netdev@...r.kernel.org>,
<bpf@...r.kernel.org>
Subject: Re: [PATCH 08/14] bpf/tests: Add tests for ALU operations implemented
with function calls
On 7/28/21 10:04 AM, Johan Almbladh wrote:
> 32-bit JITs may implement complex ALU64 instructions using function calls.
> The new tests check aspects related to this, such as register clobbering
> and register argument re-ordering.
>
> Signed-off-by: Johan Almbladh <johan.almbladh@...finetworks.com>
> ---
> lib/test_bpf.c | 138 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 138 insertions(+)
>
> diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> index eb61088a674f..1115e39630ce 100644
> --- a/lib/test_bpf.c
> +++ b/lib/test_bpf.c
> @@ -1916,6 +1916,144 @@ static struct bpf_test tests[] = {
> { },
> { { 0, -1 } }
> },
> + {
> + /*
> + * Register (non-)clobbering test, in the case where a 32-bit
> + * JIT implements complex ALU64 operations via function calls.
> + */
> + "INT: Register clobbering, R1 updated",
> + .u.insns_int = {
> + BPF_ALU32_IMM(BPF_MOV, R0, 0),
> + BPF_ALU32_IMM(BPF_MOV, R1, 123456789),
> + BPF_ALU32_IMM(BPF_MOV, R2, 2),
> + BPF_ALU32_IMM(BPF_MOV, R3, 3),
> + BPF_ALU32_IMM(BPF_MOV, R4, 4),
> + BPF_ALU32_IMM(BPF_MOV, R5, 5),
> + BPF_ALU32_IMM(BPF_MOV, R6, 6),
> + BPF_ALU32_IMM(BPF_MOV, R7, 7),
> + BPF_ALU32_IMM(BPF_MOV, R8, 8),
> + BPF_ALU32_IMM(BPF_MOV, R9, 9),
> + BPF_ALU64_IMM(BPF_DIV, R1, 123456789),
> + BPF_JMP_IMM(BPF_JNE, R0, 0, 10),
> + BPF_JMP_IMM(BPF_JNE, R1, 1, 9),
> + BPF_JMP_IMM(BPF_JNE, R2, 2, 8),
> + BPF_JMP_IMM(BPF_JNE, R3, 3, 7),
> + BPF_JMP_IMM(BPF_JNE, R4, 4, 6),
> + BPF_JMP_IMM(BPF_JNE, R5, 5, 5),
> + BPF_JMP_IMM(BPF_JNE, R6, 6, 4),
> + BPF_JMP_IMM(BPF_JNE, R7, 7, 3),
> + BPF_JMP_IMM(BPF_JNE, R8, 8, 2),
> + BPF_JMP_IMM(BPF_JNE, R9, 9, 1),
> + BPF_ALU32_IMM(BPF_MOV, R0, 1),
> + BPF_EXIT_INSN(),
> + },
> + INTERNAL,
> + { },
> + { { 0, 1 } }
> + },
> + {
> + "INT: Register clobbering, R2 updated",
> + .u.insns_int = {
> + BPF_ALU32_IMM(BPF_MOV, R0, 0),
> + BPF_ALU32_IMM(BPF_MOV, R1, 1),
> + BPF_ALU32_IMM(BPF_MOV, R2, 2 * 123456789),
> + BPF_ALU32_IMM(BPF_MOV, R3, 3),
> + BPF_ALU32_IMM(BPF_MOV, R4, 4),
> + BPF_ALU32_IMM(BPF_MOV, R5, 5),
> + BPF_ALU32_IMM(BPF_MOV, R6, 6),
> + BPF_ALU32_IMM(BPF_MOV, R7, 7),
> + BPF_ALU32_IMM(BPF_MOV, R8, 8),
> + BPF_ALU32_IMM(BPF_MOV, R9, 9),
> + BPF_ALU64_IMM(BPF_DIV, R2, 123456789),
> + BPF_JMP_IMM(BPF_JNE, R0, 0, 10),
> + BPF_JMP_IMM(BPF_JNE, R1, 1, 9),
> + BPF_JMP_IMM(BPF_JNE, R2, 2, 8),
> + BPF_JMP_IMM(BPF_JNE, R3, 3, 7),
> + BPF_JMP_IMM(BPF_JNE, R4, 4, 6),
> + BPF_JMP_IMM(BPF_JNE, R5, 5, 5),
> + BPF_JMP_IMM(BPF_JNE, R6, 6, 4),
> + BPF_JMP_IMM(BPF_JNE, R7, 7, 3),
> + BPF_JMP_IMM(BPF_JNE, R8, 8, 2),
> + BPF_JMP_IMM(BPF_JNE, R9, 9, 1),
> + BPF_ALU32_IMM(BPF_MOV, R0, 1),
> + BPF_EXIT_INSN(),
> + },
> + INTERNAL,
> + { },
> + { { 0, 1 } }
> + },
It looks like the above two tests, "R1 updated" and "R2 updated" should
be very similar and the only difference is one immediate is 123456789
and another is 2 * 123456789. But for generated code, they all just have
the final immediate. Could you explain what the difference in terms of
jit for the above two tests?
> + {
> + /*
> + * Test 32-bit JITs that implement complex ALU64 operations as
> + * function calls R0 = f(R1, R2), and must re-arrange operands.
> + */
> +#define NUMER 0xfedcba9876543210ULL
> +#define DENOM 0x0123456789abcdefULL
> + "ALU64_DIV X: Operand register permutations",
> + .u.insns_int = {
> + /* R0 / R2 */
> + BPF_LD_IMM64(R0, NUMER),
> + BPF_LD_IMM64(R2, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R0, R2),
> + BPF_JMP_IMM(BPF_JEQ, R0, NUMER / DENOM, 1),
> + BPF_EXIT_INSN(),
> + /* R1 / R0 */
> + BPF_LD_IMM64(R1, NUMER),
> + BPF_LD_IMM64(R0, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R1, R0),
> + BPF_JMP_IMM(BPF_JEQ, R1, NUMER / DENOM, 1),
> + BPF_EXIT_INSN(),
> + /* R0 / R1 */
> + BPF_LD_IMM64(R0, NUMER),
> + BPF_LD_IMM64(R1, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R0, R1),
> + BPF_JMP_IMM(BPF_JEQ, R0, NUMER / DENOM, 1),
> + BPF_EXIT_INSN(),
> + /* R2 / R0 */
> + BPF_LD_IMM64(R2, NUMER),
> + BPF_LD_IMM64(R0, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R2, R0),
> + BPF_JMP_IMM(BPF_JEQ, R2, NUMER / DENOM, 1),
> + BPF_EXIT_INSN(),
> + /* R2 / R1 */
> + BPF_LD_IMM64(R2, NUMER),
> + BPF_LD_IMM64(R1, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R2, R1),
> + BPF_JMP_IMM(BPF_JEQ, R2, NUMER / DENOM, 1),
> + BPF_EXIT_INSN(),
> + /* R1 / R2 */
> + BPF_LD_IMM64(R1, NUMER),
> + BPF_LD_IMM64(R2, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R1, R2),
> + BPF_JMP_IMM(BPF_JEQ, R1, NUMER / DENOM, 1),
> + BPF_EXIT_INSN(),
> + BPF_LD_IMM64(R0, 1),
Do we need this BPF_LD_IMM64(R0, 1)?
First, if we have it, and next "BPF_ALU64_REG(BPF_DIV, R1, R1)"
generates incorrect value and exit and then you will get
exit value 1, which will signal the test success.
Second, if you don't have this R0 = 1, R0 will be DENOM
and you will be fine.
> + /* R1 / R1 */
> + BPF_LD_IMM64(R1, NUMER),
> + BPF_ALU64_REG(BPF_DIV, R1, R1),
> + BPF_JMP_IMM(BPF_JEQ, R1, 1, 1),
> + BPF_EXIT_INSN(),
> + /* R2 / R2 */
> + BPF_LD_IMM64(R2, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R2, R2),
> + BPF_JMP_IMM(BPF_JEQ, R2, 1, 1),
> + BPF_EXIT_INSN(),
> + /* R3 / R4 */
> + BPF_LD_IMM64(R3, NUMER),
> + BPF_LD_IMM64(R4, DENOM),
> + BPF_ALU64_REG(BPF_DIV, R3, R4),
> + BPF_JMP_IMM(BPF_JEQ, R3, NUMER / DENOM, 1),
> + BPF_EXIT_INSN(),
> + /* Successful return */
> + BPF_LD_IMM64(R0, 1),
> + BPF_EXIT_INSN(),
> + },
> + INTERNAL,
> + { },
> + { { 0, 1 } },
> +#undef NUMER
> +#undef DENOM
> + },
> {
> "check: missing ret",
> .u.insns = {
>
Powered by blists - more mailing lists