Message ID | 20240130040958.230673-1-pulehui@huaweicloud.com (mailing list archive) |
---|---|
Headers | show
Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8A2E374EE; Tue, 30 Jan 2024 04:09:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706587757; cv=none; b=BNFsHGibcfTMCbJCt2gco4Tc9Rn8WO46MhuBvoyAH5azN2WlC57rxZwVMN2vhxFw27+B1o7f435mv9rGHgXEnJR9JC23WMUZhjoPwpu9iS/5oV1us+s0gKlr5ojzqOGLLVtWdM82GJu7Nlwamuh8fpZu+VnMNHvk5mRfujRQVbA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706587757; c=relaxed/simple; bh=9M/1QACtJ97wLTj9lb5xT8ggZrzWDV9amgWqvRAOKag=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=CzPZZmDH3j2kCKCKJjQQKziQ0g3WP/OyuM907lv7spqgrOVLtOmSrTmHyI09Qoxfsme5I+LsvMiA9JcBCHy1kGixlwFay2QecXk21Fj1HdxfiEOyl46tF7sRVTKJSzjfaktb++SI3G+RWGDsMqUTVcrz3Y8RZAUAFipBc8zYTj0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4TPBW717SYz4f3kFD; Tue, 30 Jan 2024 12:09:07 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 45C691A0283; Tue, 30 Jan 2024 12:09:11 +0800 (CST) Received: from ultra.huawei.com (unknown [10.90.53.71]) by APP2 (Coremail) with SMTP id Syh0CgCHqg1ldrhlqljQCQ--.26624S2; Tue, 30 Jan 2024 12:09:09 +0800 (CST) From: Pu Lehui <pulehui@huaweicloud.com> To: bpf@vger.kernel.org, linux-riscv@lists.infradead.org, netdev@vger.kernel.org Cc: =?utf-8?b?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>, Song Liu <song@kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Eduard Zingerman <eddyz87@gmail.com>, Yonghong Song <yhs@fb.com>, John Fastabend <john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Luke Nelson <luke.r.nels@gmail.com>, Pu Lehui <pulehui@huawei.com>, Pu Lehui <pulehui@huaweicloud.com> Subject: [PATCH bpf-next v2 0/4] Mixing bpf2bpf and tailcalls for RV64 Date: Tue, 30 Jan 2024 04:09:54 +0000 Message-Id: <20240130040958.230673-1-pulehui@huaweicloud.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: <bpf.vger.kernel.org> List-Subscribe: <mailto:bpf+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:bpf+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: Syh0CgCHqg1ldrhlqljQCQ--.26624S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Cr1kKFyrCF4DGF15ZFWrKrg_yoW8Wry3pa y3Ww13Gr1kXryxCw42ya18Ja4rGF4fA3W3Ar13tr1Fya1rCFyqgF1xGFWFqFyUAFZ2934j vF4Utan8CayUZ3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv014x267AKxVW5JVWrJwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628v n2kIc2xKxwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_GFv_Wryl IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7VU1 22NtUUUUU== X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ X-Patchwork-Delegate: bpf@iogearbox.net |
Series |
Mixing bpf2bpf and tailcalls for RV64
|
expand
|
From: Pu Lehui <pulehui@huawei.com> In the current RV64 JIT, if we just don't initialize the TCC in subprog, the TCC can be propagated from the parent process to the subprocess, but the TCC of the parent process cannot be restored when the subprocess exits. Since the RV64 TCC is initialized before saving the callee saved registers into the stack, we cannot use the callee saved register to pass the TCC, otherwise the original value of the callee saved register will be destroyed. So we implemented mixing bpf2bpf and tailcalls similar to x86_64, i.e. using a non-callee saved register to transfer the TCC between functions, and saving that register to the stack to protect the TCC value. At the same time, we also consider the scenario of mixing trampoline. In addition, some code cleans are also attached to this patchset. Tests test_bpf.ko and test_verifier have passed, as well as the relative testcases of test_progs*. v2: - Fix emit restore RV_REG_TCC double times when `flags & BPF_TRAMP_F_CALL_ORIG` - Use bpf_is_subprog helper v1: https://lore.kernel.org/bpf/20230919035711.3297256-1-pulehui@huaweicloud.com Pu Lehui (4): riscv, bpf: Remove redundant ctx->offset initialization riscv, bpf: Using kvcalloc to allocate cache buffer riscv, bpf: Add RV_TAILCALL_OFFSET macro to format tailcall offset riscv, bpf: Mixing bpf2bpf and tailcalls arch/riscv/net/bpf_jit.h | 1 + arch/riscv/net/bpf_jit_comp64.c | 102 ++++++++++++++------------------ arch/riscv/net/bpf_jit_core.c | 9 +-- 3 files changed, 46 insertions(+), 66 deletions(-)