[PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Pu Lehui]

Add Zbb support [0] to optimize code size and performance of RV64 JIT.
Meanwhile, adjust the code for unification and simplification. Tests
test_bpf.ko and test_verifier have passed, as well as the relative
testcases of test_progs*.

Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]

v3 resend:
- resend for mail be treated as spam.

v3:
- Change to early-exit code style and make code more explicit.

v2: https://lore.kernel.org/bpf/20230919035839.3297328-1-pulehui@huaweicloud.com
- Add runtime detection for Zbb instructions.
- Correct formatting issues detected by checkpatch.

v1: https://lore.kernel.org/bpf/20230913153413.1446068-1-pulehui@huaweicloud.com

Pu Lehui (6):
  riscv, bpf: Unify 32-bit sign-extension to emit_sextw
  riscv, bpf: Unify 32-bit zero-extension to emit_zextw
  riscv, bpf: Simplify sext and zext logics in branch instructions
  riscv, bpf: Add necessary Zbb instructions
  riscv, bpf: Optimize sign-extention mov insns with Zbb support
  riscv, bpf: Optimize bswap insns with Zbb support

 arch/riscv/net/bpf_jit.h        | 134 ++++++++++++++++++++
 arch/riscv/net/bpf_jit_comp64.c | 210 +++++++++++---------------------
 2 files changed, 205 insertions(+), 139 deletions(-)

-- 
2.34.1

[PATCH RESEND bpf-next v3 1/6] riscv, bpf: Unify 32-bit sign-extension to emit_sextw

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

For code unification, add emit_sextw wrapper to unify all the 32-bit
sign-extension operations.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
Acked-by: Björn Töpel <bjorn@kernel.org>
---
 arch/riscv/net/bpf_jit.h        |  5 +++++
 arch/riscv/net/bpf_jit_comp64.c | 10 +++++-----
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index a5ce1ab76ece..f9f8d86e762f 100644
--- a/arch/riscv/net/bpf_jit.h
+++ b/arch/riscv/net/bpf_jit.h
@@ -1087,6 +1087,11 @@ static inline void emit_subw(u8 rd, u8 rs1, u8 rs2, struct rv_jit_context *ctx)
 		emit(rv_subw(rd, rs1, rs2), ctx);
 }
 
+static inline void emit_sextw(u8 rd, u8 rs, struct rv_jit_context *ctx)
+{
+	emit_addiw(rd, rs, 0, ctx);
+}
+
 #endif /* __riscv_xlen == 64 */
 
 void bpf_jit_build_prologue(struct rv_jit_context *ctx);
diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index 58dc64dd94a8..73f8a0938ada 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -417,8 +417,8 @@ static void emit_zext_32_rd_rs(u8 *rd, u8 *rs, struct rv_jit_context *ctx)
 
 static void emit_sext_32_rd_rs(u8 *rd, u8 *rs, struct rv_jit_context *ctx)
 {
-	emit_addiw(RV_REG_T2, *rd, 0, ctx);
-	emit_addiw(RV_REG_T1, *rs, 0, ctx);
+	emit_sextw(RV_REG_T2, *rd, ctx);
+	emit_sextw(RV_REG_T1, *rs, ctx);
 	*rd = RV_REG_T2;
 	*rs = RV_REG_T1;
 }
@@ -433,7 +433,7 @@ static void emit_zext_32_rd_t1(u8 *rd, struct rv_jit_context *ctx)
 
 static void emit_sext_32_rd(u8 *rd, struct rv_jit_context *ctx)
 {
-	emit_addiw(RV_REG_T2, *rd, 0, ctx);
+	emit_sextw(RV_REG_T2, *rd, ctx);
 	*rd = RV_REG_T2;
 }
 
@@ -1103,7 +1103,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_srai(rd, RV_REG_T1, 64 - insn->off, ctx);
 			break;
 		case 32:
-			emit_addiw(rd, rs, 0, ctx);
+			emit_sextw(rd, rs, ctx);
 			break;
 		}
 		if (!is64 && !aux->verifier_zext)
@@ -1503,7 +1503,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		 * as t1 is used only in comparison against zero.
 		 */
 		if (!is64 && imm < 0)
-			emit_addiw(RV_REG_T1, RV_REG_T1, 0, ctx);
+			emit_sextw(RV_REG_T1, RV_REG_T1, ctx);
 		e = ctx->ninsns;
 		rvoff -= ninsns_rvoff(e - s);
 		emit_branch(BPF_JNE, RV_REG_T1, RV_REG_ZERO, rvoff, ctx);
-- 
2.34.1

[PATCH RESEND bpf-next v3 2/6] riscv, bpf: Unify 32-bit zero-extension to emit_zextw

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

For code unification, add emit_zextw wrapper to unify all the 32-bit
zero-extension operations.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
Acked-by: Björn Töpel <bjorn@kernel.org>
---
 arch/riscv/net/bpf_jit.h        |  6 +++
 arch/riscv/net/bpf_jit_comp64.c | 80 +++++++++++++++------------------
 2 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index f9f8d86e762f..e30501b46f8f 100644
--- a/arch/riscv/net/bpf_jit.h
+++ b/arch/riscv/net/bpf_jit.h
@@ -1092,6 +1092,12 @@ static inline void emit_sextw(u8 rd, u8 rs, struct rv_jit_context *ctx)
 	emit_addiw(rd, rs, 0, ctx);
 }
 
+static inline void emit_zextw(u8 rd, u8 rs, struct rv_jit_context *ctx)
+{
+	emit_slli(rd, rs, 32, ctx);
+	emit_srli(rd, rd, 32, ctx);
+}
+
 #endif /* __riscv_xlen == 64 */
 
 void bpf_jit_build_prologue(struct rv_jit_context *ctx);
diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index 73f8a0938ada..20deb906e495 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -326,12 +326,6 @@ static void emit_branch(u8 cond, u8 rd, u8 rs, int rvoff,
 	emit(rv_jalr(RV_REG_ZERO, RV_REG_T1, lower), ctx);
 }
 
-static void emit_zext_32(u8 reg, struct rv_jit_context *ctx)
-{
-	emit_slli(reg, reg, 32, ctx);
-	emit_srli(reg, reg, 32, ctx);
-}
-
 static int emit_bpf_tail_call(int insn, struct rv_jit_context *ctx)
 {
 	int tc_ninsn, off, start_insn = ctx->ninsns;
@@ -346,7 +340,7 @@ static int emit_bpf_tail_call(int insn, struct rv_jit_context *ctx)
 	 */
 	tc_ninsn = insn ? ctx->offset[insn] - ctx->offset[insn - 1] :
 		   ctx->offset[0];
-	emit_zext_32(RV_REG_A2, ctx);
+	emit_zextw(RV_REG_A2, RV_REG_A2, ctx);
 
 	off = offsetof(struct bpf_array, map.max_entries);
 	if (is_12b_check(off, insn))
@@ -408,9 +402,9 @@ static void init_regs(u8 *rd, u8 *rs, const struct bpf_insn *insn,
 static void emit_zext_32_rd_rs(u8 *rd, u8 *rs, struct rv_jit_context *ctx)
 {
 	emit_mv(RV_REG_T2, *rd, ctx);
-	emit_zext_32(RV_REG_T2, ctx);
+	emit_zextw(RV_REG_T2, RV_REG_T2, ctx);
 	emit_mv(RV_REG_T1, *rs, ctx);
-	emit_zext_32(RV_REG_T1, ctx);
+	emit_zextw(RV_REG_T1, RV_REG_T1, ctx);
 	*rd = RV_REG_T2;
 	*rs = RV_REG_T1;
 }
@@ -426,8 +420,8 @@ static void emit_sext_32_rd_rs(u8 *rd, u8 *rs, struct rv_jit_context *ctx)
 static void emit_zext_32_rd_t1(u8 *rd, struct rv_jit_context *ctx)
 {
 	emit_mv(RV_REG_T2, *rd, ctx);
-	emit_zext_32(RV_REG_T2, ctx);
-	emit_zext_32(RV_REG_T1, ctx);
+	emit_zextw(RV_REG_T2, RV_REG_T2, ctx);
+	emit_zextw(RV_REG_T1, RV_REG_T2, ctx);
 	*rd = RV_REG_T2;
 }
 
@@ -519,32 +513,32 @@ static void emit_atomic(u8 rd, u8 rs, s16 off, s32 imm, bool is64,
 		emit(is64 ? rv_amoadd_d(rs, rs, rd, 0, 0) :
 		     rv_amoadd_w(rs, rs, rd, 0, 0), ctx);
 		if (!is64)
-			emit_zext_32(rs, ctx);
+			emit_zextw(rs, rs, ctx);
 		break;
 	case BPF_AND | BPF_FETCH:
 		emit(is64 ? rv_amoand_d(rs, rs, rd, 0, 0) :
 		     rv_amoand_w(rs, rs, rd, 0, 0), ctx);
 		if (!is64)
-			emit_zext_32(rs, ctx);
+			emit_zextw(rs, rs, ctx);
 		break;
 	case BPF_OR | BPF_FETCH:
 		emit(is64 ? rv_amoor_d(rs, rs, rd, 0, 0) :
 		     rv_amoor_w(rs, rs, rd, 0, 0), ctx);
 		if (!is64)
-			emit_zext_32(rs, ctx);
+			emit_zextw(rs, rs, ctx);
 		break;
 	case BPF_XOR | BPF_FETCH:
 		emit(is64 ? rv_amoxor_d(rs, rs, rd, 0, 0) :
 		     rv_amoxor_w(rs, rs, rd, 0, 0), ctx);
 		if (!is64)
-			emit_zext_32(rs, ctx);
+			emit_zextw(rs, rs, ctx);
 		break;
 	/* src_reg = atomic_xchg(dst_reg + off16, src_reg); */
 	case BPF_XCHG:
 		emit(is64 ? rv_amoswap_d(rs, rs, rd, 0, 0) :
 		     rv_amoswap_w(rs, rs, rd, 0, 0), ctx);
 		if (!is64)
-			emit_zext_32(rs, ctx);
+			emit_zextw(rs, rs, ctx);
 		break;
 	/* r0 = atomic_cmpxchg(dst_reg + off16, r0, src_reg); */
 	case BPF_CMPXCHG:
@@ -1090,7 +1084,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 	case BPF_ALU64 | BPF_MOV | BPF_X:
 		if (imm == 1) {
 			/* Special mov32 for zext */
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 			break;
 		}
 		switch (insn->off) {
@@ -1107,7 +1101,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			break;
 		}
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 
 	/* dst = dst OP src */
@@ -1115,7 +1109,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 	case BPF_ALU64 | BPF_ADD | BPF_X:
 		emit_add(rd, rd, rs, ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_SUB | BPF_X:
 	case BPF_ALU64 | BPF_SUB | BPF_X:
@@ -1125,31 +1119,31 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_subw(rd, rd, rs, ctx);
 
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_AND | BPF_X:
 	case BPF_ALU64 | BPF_AND | BPF_X:
 		emit_and(rd, rd, rs, ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_OR | BPF_X:
 	case BPF_ALU64 | BPF_OR | BPF_X:
 		emit_or(rd, rd, rs, ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_XOR | BPF_X:
 	case BPF_ALU64 | BPF_XOR | BPF_X:
 		emit_xor(rd, rd, rs, ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_MUL | BPF_X:
 	case BPF_ALU64 | BPF_MUL | BPF_X:
 		emit(is64 ? rv_mul(rd, rd, rs) : rv_mulw(rd, rd, rs), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_DIV | BPF_X:
 	case BPF_ALU64 | BPF_DIV | BPF_X:
@@ -1158,7 +1152,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		else
 			emit(is64 ? rv_divu(rd, rd, rs) : rv_divuw(rd, rd, rs), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_MOD | BPF_X:
 	case BPF_ALU64 | BPF_MOD | BPF_X:
@@ -1167,25 +1161,25 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		else
 			emit(is64 ? rv_remu(rd, rd, rs) : rv_remuw(rd, rd, rs), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_LSH | BPF_X:
 	case BPF_ALU64 | BPF_LSH | BPF_X:
 		emit(is64 ? rv_sll(rd, rd, rs) : rv_sllw(rd, rd, rs), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_RSH | BPF_X:
 	case BPF_ALU64 | BPF_RSH | BPF_X:
 		emit(is64 ? rv_srl(rd, rd, rs) : rv_srlw(rd, rd, rs), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_ARSH | BPF_X:
 	case BPF_ALU64 | BPF_ARSH | BPF_X:
 		emit(is64 ? rv_sra(rd, rd, rs) : rv_sraw(rd, rd, rs), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 
 	/* dst = -dst */
@@ -1193,7 +1187,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 	case BPF_ALU64 | BPF_NEG:
 		emit_sub(rd, RV_REG_ZERO, rd, ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 
 	/* dst = BSWAP##imm(dst) */
@@ -1205,7 +1199,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			break;
 		case 32:
 			if (!aux->verifier_zext)
-				emit_zext_32(rd, ctx);
+				emit_zextw(rd, rd, ctx);
 			break;
 		case 64:
 			/* Do nothing */
@@ -1267,7 +1261,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 	case BPF_ALU64 | BPF_MOV | BPF_K:
 		emit_imm(rd, imm, ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 
 	/* dst = dst OP imm */
@@ -1280,7 +1274,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_add(rd, rd, RV_REG_T1, ctx);
 		}
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_SUB | BPF_K:
 	case BPF_ALU64 | BPF_SUB | BPF_K:
@@ -1291,7 +1285,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_sub(rd, rd, RV_REG_T1, ctx);
 		}
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_AND | BPF_K:
 	case BPF_ALU64 | BPF_AND | BPF_K:
@@ -1302,7 +1296,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_and(rd, rd, RV_REG_T1, ctx);
 		}
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_OR | BPF_K:
 	case BPF_ALU64 | BPF_OR | BPF_K:
@@ -1313,7 +1307,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_or(rd, rd, RV_REG_T1, ctx);
 		}
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_XOR | BPF_K:
 	case BPF_ALU64 | BPF_XOR | BPF_K:
@@ -1324,7 +1318,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_xor(rd, rd, RV_REG_T1, ctx);
 		}
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_MUL | BPF_K:
 	case BPF_ALU64 | BPF_MUL | BPF_K:
@@ -1332,7 +1326,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		emit(is64 ? rv_mul(rd, rd, RV_REG_T1) :
 		     rv_mulw(rd, rd, RV_REG_T1), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_DIV | BPF_K:
 	case BPF_ALU64 | BPF_DIV | BPF_K:
@@ -1344,7 +1338,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit(is64 ? rv_divu(rd, rd, RV_REG_T1) :
 			     rv_divuw(rd, rd, RV_REG_T1), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_MOD | BPF_K:
 	case BPF_ALU64 | BPF_MOD | BPF_K:
@@ -1356,14 +1350,14 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit(is64 ? rv_remu(rd, rd, RV_REG_T1) :
 			     rv_remuw(rd, rd, RV_REG_T1), ctx);
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_LSH | BPF_K:
 	case BPF_ALU64 | BPF_LSH | BPF_K:
 		emit_slli(rd, rd, imm, ctx);
 
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_RSH | BPF_K:
 	case BPF_ALU64 | BPF_RSH | BPF_K:
@@ -1373,7 +1367,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit(rv_srliw(rd, rd, imm), ctx);
 
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 	case BPF_ALU | BPF_ARSH | BPF_K:
 	case BPF_ALU64 | BPF_ARSH | BPF_K:
@@ -1383,7 +1377,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit(rv_sraiw(rd, rd, imm), ctx);
 
 		if (!is64 && !aux->verifier_zext)
-			emit_zext_32(rd, ctx);
+			emit_zextw(rd, rd, ctx);
 		break;
 
 	/* JUMP off */
-- 
2.34.1

[PATCH RESEND bpf-next v3 3/6] riscv, bpf: Simplify sext and zext logics in branch instructions

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

There are many extension helpers in the current branch instructions, and
the implementation is a bit complicated. We simplify this logic through
two simple extension helpers with alternate register.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
 arch/riscv/net/bpf_jit_comp64.c | 79 +++++++++++++--------------------
 1 file changed, 31 insertions(+), 48 deletions(-)

diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index 20deb906e495..d90784674677 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -141,6 +141,19 @@ static bool in_auipc_jalr_range(s64 val)
 		val < ((1L << 31) - (1L << 11));
 }
 
+/* Modify rd pointer to alternate reg to avoid corrupting original reg */
+static void emit_sextw_alt(u8 *rd, u8 ra, struct rv_jit_context *ctx)
+{
+	emit_sextw(ra, *rd, ctx);
+	*rd = ra;
+}
+
+static void emit_zextw_alt(u8 *rd, u8 ra, struct rv_jit_context *ctx)
+{
+	emit_zextw(ra, *rd, ctx);
+	*rd = ra;
+}
+
 /* Emit fixed-length instructions for address */
 static int emit_addr(u8 rd, u64 addr, bool extra_pass, struct rv_jit_context *ctx)
 {
@@ -399,38 +412,6 @@ static void init_regs(u8 *rd, u8 *rs, const struct bpf_insn *insn,
 		*rs = bpf_to_rv_reg(insn->src_reg, ctx);
 }
 
-static void emit_zext_32_rd_rs(u8 *rd, u8 *rs, struct rv_jit_context *ctx)
-{
-	emit_mv(RV_REG_T2, *rd, ctx);
-	emit_zextw(RV_REG_T2, RV_REG_T2, ctx);
-	emit_mv(RV_REG_T1, *rs, ctx);
-	emit_zextw(RV_REG_T1, RV_REG_T1, ctx);
-	*rd = RV_REG_T2;
-	*rs = RV_REG_T1;
-}
-
-static void emit_sext_32_rd_rs(u8 *rd, u8 *rs, struct rv_jit_context *ctx)
-{
-	emit_sextw(RV_REG_T2, *rd, ctx);
-	emit_sextw(RV_REG_T1, *rs, ctx);
-	*rd = RV_REG_T2;
-	*rs = RV_REG_T1;
-}
-
-static void emit_zext_32_rd_t1(u8 *rd, struct rv_jit_context *ctx)
-{
-	emit_mv(RV_REG_T2, *rd, ctx);
-	emit_zextw(RV_REG_T2, RV_REG_T2, ctx);
-	emit_zextw(RV_REG_T1, RV_REG_T2, ctx);
-	*rd = RV_REG_T2;
-}
-
-static void emit_sext_32_rd(u8 *rd, struct rv_jit_context *ctx)
-{
-	emit_sextw(RV_REG_T2, *rd, ctx);
-	*rd = RV_REG_T2;
-}
-
 static int emit_jump_and_link(u8 rd, s64 rvoff, bool fixed_addr,
 			      struct rv_jit_context *ctx)
 {
@@ -1418,10 +1399,13 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		rvoff = rv_offset(i, off, ctx);
 		if (!is64) {
 			s = ctx->ninsns;
-			if (is_signed_bpf_cond(BPF_OP(code)))
-				emit_sext_32_rd_rs(&rd, &rs, ctx);
-			else
-				emit_zext_32_rd_rs(&rd, &rs, ctx);
+			if (is_signed_bpf_cond(BPF_OP(code))) {
+				emit_sextw_alt(&rs, RV_REG_T1, ctx);
+				emit_sextw_alt(&rd, RV_REG_T2, ctx);
+			} else {
+				emit_zextw_alt(&rs, RV_REG_T1, ctx);
+				emit_zextw_alt(&rd, RV_REG_T2, ctx);
+			}
 			e = ctx->ninsns;
 
 			/* Adjust for extra insns */
@@ -1432,8 +1416,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			/* Adjust for and */
 			rvoff -= 4;
 			emit_and(RV_REG_T1, rd, rs, ctx);
-			emit_branch(BPF_JNE, RV_REG_T1, RV_REG_ZERO, rvoff,
-				    ctx);
+			emit_branch(BPF_JNE, RV_REG_T1, RV_REG_ZERO, rvoff, ctx);
 		} else {
 			emit_branch(BPF_OP(code), rd, rs, rvoff, ctx);
 		}
@@ -1462,18 +1445,18 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 	case BPF_JMP32 | BPF_JSLE | BPF_K:
 		rvoff = rv_offset(i, off, ctx);
 		s = ctx->ninsns;
-		if (imm) {
+		if (imm)
 			emit_imm(RV_REG_T1, imm, ctx);
-			rs = RV_REG_T1;
-		} else {
-			/* If imm is 0, simply use zero register. */
-			rs = RV_REG_ZERO;
-		}
+		rs = imm ? RV_REG_T1 : RV_REG_ZERO;
 		if (!is64) {
-			if (is_signed_bpf_cond(BPF_OP(code)))
-				emit_sext_32_rd(&rd, ctx);
-			else
-				emit_zext_32_rd_t1(&rd, ctx);
+			if (is_signed_bpf_cond(BPF_OP(code))) {
+				emit_sextw_alt(&rd, RV_REG_T2, ctx);
+				/* rs has been sign extended */
+			} else {
+				emit_zextw_alt(&rd, RV_REG_T2, ctx);
+				if (imm)
+					emit_zextw(rs, rs, ctx);
+			}
 		}
 		e = ctx->ninsns;
 
-- 
2.34.1

[PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

Add necessary Zbb instructions introduced by [0] to reduce code size and
improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
added to check whether the CPU supports Zbb instructions.

Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
 arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index e30501b46f8f..51f6d214086f 100644
--- a/arch/riscv/net/bpf_jit.h
+++ b/arch/riscv/net/bpf_jit.h
@@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
 	return IS_ENABLED(CONFIG_RISCV_ISA_C);
 }
 
+static inline bool rvzbb_enabled(void)
+{
+	return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
+}
+
 enum {
 	RV_REG_ZERO =	0,	/* The constant value 0 */
 	RV_REG_RA =	1,	/* Return address */
@@ -730,6 +735,33 @@ static inline u16 rvc_swsp(u32 imm8, u8 rs2)
 	return rv_css_insn(0x6, imm, rs2, 0x2);
 }
 
+/* RVZBB instrutions. */
+static inline u32 rvzbb_sextb(u8 rd, u8 rs1)
+{
+	return rv_i_insn(0x604, rs1, 1, rd, 0x13);
+}
+
+static inline u32 rvzbb_sexth(u8 rd, u8 rs1)
+{
+	return rv_i_insn(0x605, rs1, 1, rd, 0x13);
+}
+
+static inline u32 rvzbb_zexth(u8 rd, u8 rs)
+{
+	if (IS_ENABLED(CONFIG_64BIT))
+		return rv_i_insn(0x80, rs, 4, rd, 0x3b);
+
+	return rv_i_insn(0x80, rs, 4, rd, 0x33);
+}
+
+static inline u32 rvzbb_rev8(u8 rd, u8 rs)
+{
+	if (IS_ENABLED(CONFIG_64BIT))
+		return rv_i_insn(0x6b8, rs, 5, rd, 0x13);
+
+	return rv_i_insn(0x698, rs, 5, rd, 0x13);
+}
+
 /*
  * RV64-only instructions.
  *
-- 
2.34.1

[PATCH RESEND bpf-next v3 5/6] riscv, bpf: Optimize sign-extention mov insns with Zbb support

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

Add 8-bit and 16-bit sign-extention wraper with Zbb support to optimize
sign-extension mov instructions.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
Acked-by: Björn Töpel <bjorn@kernel.org>
---
 arch/riscv/net/bpf_jit.h        | 22 ++++++++++++++++++++++
 arch/riscv/net/bpf_jit_comp64.c |  5 +++--
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index 51f6d214086f..b00c5c0591d2 100644
--- a/arch/riscv/net/bpf_jit.h
+++ b/arch/riscv/net/bpf_jit.h
@@ -1119,6 +1119,28 @@ static inline void emit_subw(u8 rd, u8 rs1, u8 rs2, struct rv_jit_context *ctx)
 		emit(rv_subw(rd, rs1, rs2), ctx);
 }
 
+static inline void emit_sextb(u8 rd, u8 rs, struct rv_jit_context *ctx)
+{
+	if (rvzbb_enabled()) {
+		emit(rvzbb_sextb(rd, rs), ctx);
+		return;
+	}
+
+	emit_slli(rd, rs, 56, ctx);
+	emit_srai(rd, rd, 56, ctx);
+}
+
+static inline void emit_sexth(u8 rd, u8 rs, struct rv_jit_context *ctx)
+{
+	if (rvzbb_enabled()) {
+		emit(rvzbb_sexth(rd, rs), ctx);
+		return;
+	}
+
+	emit_slli(rd, rs, 48, ctx);
+	emit_srai(rd, rd, 48, ctx);
+}
+
 static inline void emit_sextw(u8 rd, u8 rs, struct rv_jit_context *ctx)
 {
 	emit_addiw(rd, rs, 0, ctx);
diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index d90784674677..18bbf8122eb3 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -1073,9 +1073,10 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			emit_mv(rd, rs, ctx);
 			break;
 		case 8:
+			emit_sextb(rd, rs, ctx);
+			break;
 		case 16:
-			emit_slli(RV_REG_T1, rs, 64 - insn->off, ctx);
-			emit_srai(rd, RV_REG_T1, 64 - insn->off, ctx);
+			emit_sexth(rd, rs, ctx);
 			break;
 		case 32:
 			emit_sextw(rd, rs, ctx);
-- 
2.34.1

[PATCH RESEND bpf-next v3 6/6] riscv, bpf: Optimize bswap insns with Zbb support

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

Optimize bswap instructions by rev8 Zbb instruction conbined with srli
instruction. And Optimize 16-bit zero-extension with Zbb support.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
 arch/riscv/net/bpf_jit.h        | 69 +++++++++++++++++++++++++++++++++
 arch/riscv/net/bpf_jit_comp64.c | 50 +-----------------------
 2 files changed, 71 insertions(+), 48 deletions(-)

diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index b00c5c0591d2..8b35f12a4452 100644
--- a/arch/riscv/net/bpf_jit.h
+++ b/arch/riscv/net/bpf_jit.h
@@ -1146,12 +1146,81 @@ static inline void emit_sextw(u8 rd, u8 rs, struct rv_jit_context *ctx)
 	emit_addiw(rd, rs, 0, ctx);
 }
 
+static inline void emit_zexth(u8 rd, u8 rs, struct rv_jit_context *ctx)
+{
+	if (rvzbb_enabled()) {
+		emit(rvzbb_zexth(rd, rs), ctx);
+		return;
+	}
+
+	emit_slli(rd, rs, 48, ctx);
+	emit_srli(rd, rd, 48, ctx);
+}
+
 static inline void emit_zextw(u8 rd, u8 rs, struct rv_jit_context *ctx)
 {
 	emit_slli(rd, rs, 32, ctx);
 	emit_srli(rd, rd, 32, ctx);
 }
 
+static inline void emit_bswap(u8 rd, s32 imm, struct rv_jit_context *ctx)
+{
+	if (rvzbb_enabled()) {
+		int bits = 64 - imm;
+
+		emit(rvzbb_rev8(rd, rd), ctx);
+		if (bits)
+			emit_srli(rd, rd, bits, ctx);
+		return;
+	}
+
+	emit_li(RV_REG_T2, 0, ctx);
+
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+	emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
+	emit_srli(rd, rd, 8, ctx);
+	if (imm == 16)
+		goto out_be;
+
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+	emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
+	emit_srli(rd, rd, 8, ctx);
+
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+	emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
+	emit_srli(rd, rd, 8, ctx);
+	if (imm == 32)
+		goto out_be;
+
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+	emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
+	emit_srli(rd, rd, 8, ctx);
+
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+	emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
+	emit_srli(rd, rd, 8, ctx);
+
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+	emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
+	emit_srli(rd, rd, 8, ctx);
+
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+	emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
+	emit_srli(rd, rd, 8, ctx);
+out_be:
+	emit_andi(RV_REG_T1, rd, 0xff, ctx);
+	emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
+
+	emit_mv(rd, RV_REG_T2, ctx);
+}
+
 #endif /* __riscv_xlen == 64 */
 
 void bpf_jit_build_prologue(struct rv_jit_context *ctx);
diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index 18bbf8122eb3..e86e83649820 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -1176,8 +1176,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 	case BPF_ALU | BPF_END | BPF_FROM_LE:
 		switch (imm) {
 		case 16:
-			emit_slli(rd, rd, 48, ctx);
-			emit_srli(rd, rd, 48, ctx);
+			emit_zexth(rd, rd, ctx);
 			break;
 		case 32:
 			if (!aux->verifier_zext)
@@ -1188,54 +1187,9 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 			break;
 		}
 		break;
-
 	case BPF_ALU | BPF_END | BPF_FROM_BE:
 	case BPF_ALU64 | BPF_END | BPF_FROM_LE:
-		emit_li(RV_REG_T2, 0, ctx);
-
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-		emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
-		emit_srli(rd, rd, 8, ctx);
-		if (imm == 16)
-			goto out_be;
-
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-		emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
-		emit_srli(rd, rd, 8, ctx);
-
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-		emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
-		emit_srli(rd, rd, 8, ctx);
-		if (imm == 32)
-			goto out_be;
-
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-		emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
-		emit_srli(rd, rd, 8, ctx);
-
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-		emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
-		emit_srli(rd, rd, 8, ctx);
-
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-		emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
-		emit_srli(rd, rd, 8, ctx);
-
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-		emit_slli(RV_REG_T2, RV_REG_T2, 8, ctx);
-		emit_srli(rd, rd, 8, ctx);
-out_be:
-		emit_andi(RV_REG_T1, rd, 0xff, ctx);
-		emit_add(RV_REG_T2, RV_REG_T2, RV_REG_T1, ctx);
-
-		emit_mv(rd, RV_REG_T2, ctx);
+		emit_bswap(rd, imm, ctx);
 		break;
 
 	/* dst = imm */
-- 
2.34.1

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Björn Töpel]

Pu Lehui <pulehui@huaweicloud.com> writes:

> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
> Meanwhile, adjust the code for unification and simplification. Tests
> test_bpf.ko and test_verifier have passed, as well as the relative
> testcases of test_progs*.
>
> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>
> v3 resend:
> - resend for mail be treated as spam.
>
> v3:
> - Change to early-exit code style and make code more explicit.

Lehui,

Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
6.8-rc1, I will need to wrap my head around that prior reviewing
properly.


Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Pu Lehui]

On 2024/1/22 22:33, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
> 
>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>> Meanwhile, adjust the code for unification and simplification. Tests
>> test_bpf.ko and test_verifier have passed, as well as the relative
>> testcases of test_progs*.
>>
>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>
>> v3 resend:
>> - resend for mail be treated as spam.
>>
>> v3:
>> - Change to early-exit code style and make code more explicit.
> 
> Lehui,
> 
> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
> 6.8-rc1, I will need to wrap my head around that prior reviewing
> properly.
> 

Oh, I also found the problem with struct ops and fixed it

diff --git a/arch/riscv/net/bpf_jit_comp64.c 
b/arch/riscv/net/bpf_jit_comp64.c
index 42cfd1ed295e..5c4e0ac389d0 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -795,6 +795,7 @@ static int __arch_prepare_bpf_trampoline(struct 
bpf_tramp_image *im,
         struct bpf_tramp_links *fentry = &tlinks[BPF_TRAMP_FENTRY];
         struct bpf_tramp_links *fexit = &tlinks[BPF_TRAMP_FEXIT];
         struct bpf_tramp_links *fmod_ret = 
&tlinks[BPF_TRAMP_MODIFY_RETURN];
+       bool is_struct_ops = flags & BPF_TRAMP_F_INDIRECT;
         void *orig_call = func_addr;
         bool save_ret;
         u32 insn;
@@ -878,7 +879,7 @@ static int __arch_prepare_bpf_trampoline(struct 
bpf_tramp_image *im,

         stack_size = round_up(stack_size, 16);

-       if (func_addr) {
+       if (!is_struct_ops) {
                 /* For the trampoline called from function entry,
                  * the frame of traced function and the frame of
                  * trampoline need to be considered.
@@ -998,7 +999,7 @@ static int __arch_prepare_bpf_trampoline(struct 
bpf_tramp_image *im,

         emit_ld(RV_REG_S1, -sreg_off, RV_REG_FP, ctx);

-       if (func_addr) {
+       if (!is_struct_ops) {
                 /* trampoline called from function entry */
                 emit_ld(RV_REG_T0, stack_size - 8, RV_REG_SP, ctx);
                 emit_ld(RV_REG_FP, stack_size - 16, RV_REG_SP, ctx);

> 
> Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Björn Töpel]

Pu Lehui <pulehui@huaweicloud.com> writes:

> On 2024/1/22 22:33, Björn Töpel wrote:
>> Pu Lehui <pulehui@huaweicloud.com> writes:
>> 
>>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>>> Meanwhile, adjust the code for unification and simplification. Tests
>>> test_bpf.ko and test_verifier have passed, as well as the relative
>>> testcases of test_progs*.
>>>
>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>
>>> v3 resend:
>>> - resend for mail be treated as spam.
>>>
>>> v3:
>>> - Change to early-exit code style and make code more explicit.
>> 
>> Lehui,
>> 
>> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
>> 6.8-rc1, I will need to wrap my head around that prior reviewing
>> properly.
>> 
>
> Oh, I also found the problem with struct ops and fixed it

Awesome, I just started bisecting the following test_progs sub-test
fails on 6.8-rc1:

bpf_iter_setsockopt:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Oops [#1]
Modules linked in: bpf_testmod(OE) drm fuse i2c_core dm_mod drm_panel_orientation_quirks backlight configfs ip_tables x_tables
CPU: 1 PID: 458 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
Hardware name: riscv-virtio,qemu (DT)
epc : 0x0
 ra : tcp_set_ca_state+0x2c/0x9a
epc : 0000000000000000 ra : ffffffff80cdc6b2 sp : ff2000000000b910
 gp : ffffffff82587b60 tp : ff60000087ea8040 t0 : 0000000000000000
 t1 : ffffffff801ed15e t2 : 0000000000000000 s0 : ff2000000000b930
 s1 : ff600000879296c0 a0 : ff20000000497000 a1 : 0000000000000008
 a2 : 0000000000000001 a3 : ff60000087ea83a0 a4 : 0000000000000000
 a5 : 0000000000000106 a6 : 0000000000000021 a7 : 0000000000000000
 s2 : 0000000000000000 s3 : ff60000086878008 s4 : ff60000082ce2f40
 s5 : ff60000084f56040 s6 : ff60000087929040 s7 : ff60000086878008
 s8 : ff2000000000ba5f s9 : ff60000087928a00 s10: 0000000000000002
 s11: ff60000087928040 t3 : 000000000001ffff t4 : 0100000000000000
 t5 : 0000000000000000 t6 : ff6000008792a118
status: 0000000200000120 badaddr: 0000000000000000 cause: 000000000000000c
Code: Unable to access instruction at 0xffffffffffffffec.
---[ end trace 0000000000000000 ]---

bpf_tcp_ca:
Unable to handle kernel paging request at virtual address ff60000088554500
Oops [#1]
Modules linked in: iptable_raw xt_connmark bpf_testmod(OE) drm fuse i2c_core drm_panel_orientation_quirks backlight dm_mod configfs ip_tables x_tables [last unloaded: bpf_testmod(OE)]
CPU: 3 PID: 458 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
Hardware name: riscv-virtio,qemu (DT)
epc : 0xff60000088554500
 ra : tcp_ack+0x288/0x1232
epc : ff60000088554500 ra : ffffffff80cc7166 sp : ff2000000117ba50
 gp : ffffffff82587b60 tp : ff60000087be0040 t0 : ff60000088554500
 t1 : ffffffff801ed24e t2 : 0000000000000000 s0 : ff2000000117bbc0
 s1 : 0000000000000500 a0 : ff20000000691000 a1 : 0000000000000018
 a2 : 0000000000000001 a3 : ff60000087be03a0 a4 : 0000000000000000
 a5 : 0000000000000000 a6 : 0000000000000021 a7 : ffffffff8263f880
 s2 : 000000004ac3c13b s3 : 000000004ac3c13a s4 : 0000000000008200
 s5 : 0000000000000001 s6 : 0000000000000104 s7 : ff2000000117bb00
 s8 : ff600000885544c0 s9 : 0000000000000000 s10: ff60000086ff0b80
 s11: 000055557983a9c0 t3 : 0000000000000000 t4 : 000000000000ffc4
 t5 : ffffffff8154f170 t6 : 0000000000000030
status: 0000000200000120 badaddr: ff60000088554500 cause: 000000000000000c
Code: c796 67d7 0000 0000 0052 0002 c13b 4ac3 0000 0000 (0001) 0000 
---[ end trace 0000000000000000 ]---

dummy_st_ops:
Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000043022
Oops [#1]
Modules linked in: iptable_raw xt_connmark bpf_testmod(OE) drm fuse i2c_core drm_panel_orientation_quirks backlight dm_mod configfs ip_tables x_tables [last unloaded: bpf_testmod(OE)]
CPU: 1 PID: 452 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
Hardware name: riscv-virtio,qemu (DT)
epc : 0x43022
 ra : bpf_struct_ops_test_run+0x188/0x37a
epc : 0000000000043022 ra : ffffffff80c75d1a sp : ff200000002a3ce0
 gp : ffffffff82587b60 tp : ff6000008356b840 t0 : 0000000000043023
 t1 : ffffffff801ed062 t2 : 000000000000ff00 s0 : ff200000002a3d40
 s1 : ffffffff78207000 a0 : fffffffff2f3f4f5 a1 : 0000000000000008
 a2 : 0000000000000001 a3 : ff6000008356bba0 a4 : 0000000000000000
 a5 : fffffffff2f3f4f5 a6 : 0000000000000021 a7 : 0000000052464e43
 s2 : 0000000000000000 s3 : ff60000080b33b80 s4 : 0000000000000084
 s5 : ff60000083334c00 s6 : ff60000084861580 s7 : 00007ffff0887668
 s8 : 00007fffaa859030 s9 : 0000000000000000 s10: 000055556631ca4c
 s11: 000055556631c9c0 t3 : 000000000000000f t4 : 0000000000000800
 t5 : 0001000000000000 t6 : ff6000008adb9bf8
status: 0000000200000120 badaddr: 0000000000043022 cause: 000000000000000c
Code: Unable to access instruction at 0x000000000004300e.
---[ end trace 0000000000000000 ]---

Environment: OpenSBI 1.4, Qemu 8.2.0, U-boot UEFI

Is that the same that you see?

I'll take your patch for a spin!


Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Björn Töpel]

Björn Töpel <bjorn@kernel.org> writes:

> Pu Lehui <pulehui@huaweicloud.com> writes:
>
>> On 2024/1/22 22:33, Björn Töpel wrote:
>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>> 
>>>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>>>> Meanwhile, adjust the code for unification and simplification. Tests
>>>> test_bpf.ko and test_verifier have passed, as well as the relative
>>>> testcases of test_progs*.
>>>>
>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>
>>>> v3 resend:
>>>> - resend for mail be treated as spam.
>>>>
>>>> v3:
>>>> - Change to early-exit code style and make code more explicit.
>>> 
>>> Lehui,
>>> 
>>> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
>>> 6.8-rc1, I will need to wrap my head around that prior reviewing
>>> properly.
>>> 
>>
>> Oh, I also found the problem with struct ops and fixed it

Pu, with your patch bpf_iter_setsockopt, bpf_tcp_ca, and dummy_st_ops
passes!

Please spin a proper fixes patch, and feel free to add:

Tested-by: Björn Töpel <bjorn@rivosinc.com>
Acked-by: Björn Töpel <bjorn@kernel.org>


Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Pu Lehui]

On 2024/1/22 22:44, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
> 
>> On 2024/1/22 22:33, Björn Töpel wrote:
>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>
>>>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>>>> Meanwhile, adjust the code for unification and simplification. Tests
>>>> test_bpf.ko and test_verifier have passed, as well as the relative
>>>> testcases of test_progs*.
>>>>
>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>
>>>> v3 resend:
>>>> - resend for mail be treated as spam.
>>>>
>>>> v3:
>>>> - Change to early-exit code style and make code more explicit.
>>>
>>> Lehui,
>>>
>>> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
>>> 6.8-rc1, I will need to wrap my head around that prior reviewing
>>> properly.
>>>
>>
>> Oh, I also found the problem with struct ops and fixed it
> 
> Awesome, I just started bisecting the following test_progs sub-test
> fails on 6.8-rc1:
> 
> bpf_iter_setsockopt:
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> Oops [#1]
> Modules linked in: bpf_testmod(OE) drm fuse i2c_core dm_mod drm_panel_orientation_quirks backlight configfs ip_tables x_tables
> CPU: 1 PID: 458 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
> Hardware name: riscv-virtio,qemu (DT)
> epc : 0x0
>   ra : tcp_set_ca_state+0x2c/0x9a
> epc : 0000000000000000 ra : ffffffff80cdc6b2 sp : ff2000000000b910
>   gp : ffffffff82587b60 tp : ff60000087ea8040 t0 : 0000000000000000
>   t1 : ffffffff801ed15e t2 : 0000000000000000 s0 : ff2000000000b930
>   s1 : ff600000879296c0 a0 : ff20000000497000 a1 : 0000000000000008
>   a2 : 0000000000000001 a3 : ff60000087ea83a0 a4 : 0000000000000000
>   a5 : 0000000000000106 a6 : 0000000000000021 a7 : 0000000000000000
>   s2 : 0000000000000000 s3 : ff60000086878008 s4 : ff60000082ce2f40
>   s5 : ff60000084f56040 s6 : ff60000087929040 s7 : ff60000086878008
>   s8 : ff2000000000ba5f s9 : ff60000087928a00 s10: 0000000000000002
>   s11: ff60000087928040 t3 : 000000000001ffff t4 : 0100000000000000
>   t5 : 0000000000000000 t6 : ff6000008792a118
> status: 0000000200000120 badaddr: 0000000000000000 cause: 000000000000000c
> Code: Unable to access instruction at 0xffffffffffffffec.
> ---[ end trace 0000000000000000 ]---
> 
> bpf_tcp_ca:
> Unable to handle kernel paging request at virtual address ff60000088554500
> Oops [#1]
> Modules linked in: iptable_raw xt_connmark bpf_testmod(OE) drm fuse i2c_core drm_panel_orientation_quirks backlight dm_mod configfs ip_tables x_tables [last unloaded: bpf_testmod(OE)]
> CPU: 3 PID: 458 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
> Hardware name: riscv-virtio,qemu (DT)
> epc : 0xff60000088554500
>   ra : tcp_ack+0x288/0x1232
> epc : ff60000088554500 ra : ffffffff80cc7166 sp : ff2000000117ba50
>   gp : ffffffff82587b60 tp : ff60000087be0040 t0 : ff60000088554500
>   t1 : ffffffff801ed24e t2 : 0000000000000000 s0 : ff2000000117bbc0
>   s1 : 0000000000000500 a0 : ff20000000691000 a1 : 0000000000000018
>   a2 : 0000000000000001 a3 : ff60000087be03a0 a4 : 0000000000000000
>   a5 : 0000000000000000 a6 : 0000000000000021 a7 : ffffffff8263f880
>   s2 : 000000004ac3c13b s3 : 000000004ac3c13a s4 : 0000000000008200
>   s5 : 0000000000000001 s6 : 0000000000000104 s7 : ff2000000117bb00
>   s8 : ff600000885544c0 s9 : 0000000000000000 s10: ff60000086ff0b80
>   s11: 000055557983a9c0 t3 : 0000000000000000 t4 : 000000000000ffc4
>   t5 : ffffffff8154f170 t6 : 0000000000000030
> status: 0000000200000120 badaddr: ff60000088554500 cause: 000000000000000c
> Code: c796 67d7 0000 0000 0052 0002 c13b 4ac3 0000 0000 (0001) 0000
> ---[ end trace 0000000000000000 ]---
> 
> dummy_st_ops:
> Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000043022
> Oops [#1]
> Modules linked in: iptable_raw xt_connmark bpf_testmod(OE) drm fuse i2c_core drm_panel_orientation_quirks backlight dm_mod configfs ip_tables x_tables [last unloaded: bpf_testmod(OE)]
> CPU: 1 PID: 452 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
> Hardware name: riscv-virtio,qemu (DT)
> epc : 0x43022
>   ra : bpf_struct_ops_test_run+0x188/0x37a
> epc : 0000000000043022 ra : ffffffff80c75d1a sp : ff200000002a3ce0
>   gp : ffffffff82587b60 tp : ff6000008356b840 t0 : 0000000000043023
>   t1 : ffffffff801ed062 t2 : 000000000000ff00 s0 : ff200000002a3d40
>   s1 : ffffffff78207000 a0 : fffffffff2f3f4f5 a1 : 0000000000000008
>   a2 : 0000000000000001 a3 : ff6000008356bba0 a4 : 0000000000000000
>   a5 : fffffffff2f3f4f5 a6 : 0000000000000021 a7 : 0000000052464e43
>   s2 : 0000000000000000 s3 : ff60000080b33b80 s4 : 0000000000000084
>   s5 : ff60000083334c00 s6 : ff60000084861580 s7 : 00007ffff0887668
>   s8 : 00007fffaa859030 s9 : 0000000000000000 s10: 000055556631ca4c
>   s11: 000055556631c9c0 t3 : 000000000000000f t4 : 0000000000000800
>   t5 : 0001000000000000 t6 : ff6000008adb9bf8
> status: 0000000200000120 badaddr: 0000000000043022 cause: 000000000000000c
> Code: Unable to access instruction at 0x000000000004300e.
> ---[ end trace 0000000000000000 ]---
> 
> Environment: OpenSBI 1.4, Qemu 8.2.0, U-boot UEFI
> 
> Is that the same that you se >

Yes, is the same issue. The question is that the commit 2cd3e3772e41 
("x86/cfi,bpf: Fix bpf_struct_ops CFI") change func_addr of 
arch_prepare_bpf_trampoline from NULL to not NULL, while we use 
func_addr to distinguish struct_ops and regular trampoline. After commit 
2cd3e3772e41, we can use BPF_TRAMP_F_INDIRECT to distinguish them as it 
always be set in struct_ops.

> I'll take your patch for a spin!
> 
> 
> Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Pu Lehui]

On 2024/1/22 23:07, Björn Töpel wrote:
> Björn Töpel <bjorn@kernel.org> writes:
> 
>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>
>>> On 2024/1/22 22:33, Björn Töpel wrote:
>>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>>
>>>>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>>>>> Meanwhile, adjust the code for unification and simplification. Tests
>>>>> test_bpf.ko and test_verifier have passed, as well as the relative
>>>>> testcases of test_progs*.
>>>>>
>>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>>
>>>>> v3 resend:
>>>>> - resend for mail be treated as spam.
>>>>>
>>>>> v3:
>>>>> - Change to early-exit code style and make code more explicit.
>>>>
>>>> Lehui,
>>>>
>>>> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
>>>> 6.8-rc1, I will need to wrap my head around that prior reviewing
>>>> properly.
>>>>
>>>
>>> Oh, I also found the problem with struct ops and fixed it
> 
> Pu, with your patch bpf_iter_setsockopt, bpf_tcp_ca, and dummy_st_ops
> passes!
> 
> Please spin a proper fixes patch, and feel free to add:
> 
> Tested-by: Björn Töpel <bjorn@rivosinc.com>
> Acked-by: Björn Töpel <bjorn@kernel.org>
> 

Is that in a hurry? If not, I would like to send it with the upcoming 
patchset.

> 
> Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Björn Töpel]

Pu Lehui <pulehui@huaweicloud.com> writes:

> On 2024/1/22 23:07, Björn Töpel wrote:
>> Björn Töpel <bjorn@kernel.org> writes:
>> 
>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>
>>>> On 2024/1/22 22:33, Björn Töpel wrote:
>>>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>>>
>>>>>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>>>>>> Meanwhile, adjust the code for unification and simplification. Tests
>>>>>> test_bpf.ko and test_verifier have passed, as well as the relative
>>>>>> testcases of test_progs*.
>>>>>>
>>>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>>>
>>>>>> v3 resend:
>>>>>> - resend for mail be treated as spam.
>>>>>>
>>>>>> v3:
>>>>>> - Change to early-exit code style and make code more explicit.
>>>>>
>>>>> Lehui,
>>>>>
>>>>> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
>>>>> 6.8-rc1, I will need to wrap my head around that prior reviewing
>>>>> properly.
>>>>>
>>>>
>>>> Oh, I also found the problem with struct ops and fixed it
>> 
>> Pu, with your patch bpf_iter_setsockopt, bpf_tcp_ca, and dummy_st_ops
>> passes!
>> 
>> Please spin a proper fixes patch, and feel free to add:
>> 
>> Tested-by: Björn Töpel <bjorn@rivosinc.com>
>> Acked-by: Björn Töpel <bjorn@kernel.org>
>> 
>
> Is that in a hurry? If not, I would like to send it with the upcoming 
> patchset.

This is a separate fix, right? What patchset are you referring to where
the fix would be in?

As of now 6.8-rc1 is broken! It would be a great with a fix asap...


Cheers,
Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Pu Lehui]

On 2024/1/23 0:30, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
> 
>> On 2024/1/22 23:07, Björn Töpel wrote:
>>> Björn Töpel <bjorn@kernel.org> writes:
>>>
>>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>>
>>>>> On 2024/1/22 22:33, Björn Töpel wrote:
>>>>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>>>>
>>>>>>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>>>>>>> Meanwhile, adjust the code for unification and simplification. Tests
>>>>>>> test_bpf.ko and test_verifier have passed, as well as the relative
>>>>>>> testcases of test_progs*.
>>>>>>>
>>>>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>>>>
>>>>>>> v3 resend:
>>>>>>> - resend for mail be treated as spam.
>>>>>>>
>>>>>>> v3:
>>>>>>> - Change to early-exit code style and make code more explicit.
>>>>>>
>>>>>> Lehui,
>>>>>>
>>>>>> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
>>>>>> 6.8-rc1, I will need to wrap my head around that prior reviewing
>>>>>> properly.
>>>>>>
>>>>>
>>>>> Oh, I also found the problem with struct ops and fixed it
>>>
>>> Pu, with your patch bpf_iter_setsockopt, bpf_tcp_ca, and dummy_st_ops
>>> passes!
>>>
>>> Please spin a proper fixes patch, and feel free to add:
>>>
>>> Tested-by: Björn Töpel <bjorn@rivosinc.com>
>>> Acked-by: Björn Töpel <bjorn@kernel.org>
>>>
>>
>> Is that in a hurry? If not, I would like to send it with the upcoming
>> patchset.
> 
> This is a separate fix, right? What patchset are you referring to where
> the fix would be in?
> 

Yes, you are right! I'll send a bug fix patch as soon as possible. 
Coming soon is the bpf_prog_pack for RV64 Trampoline, which currently 
does not seem to be related to the bugfix, will populate the commit 
message and send it later.😁

> As of now 6.8-rc1 is broken! It would be a great with a fix asap...
> 
> 
> Cheers,
> Björn

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[Björn Töpel]

Pu Lehui <pulehui@huaweicloud.com> writes:

> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
> Meanwhile, adjust the code for unification and simplification. Tests
> test_bpf.ko and test_verifier have passed, as well as the relative
> testcases of test_progs*.

Lehui, apologies for the delay. Nice work! I have a minor comment in
patch 4, but not a blocker...

For the series,

Tested-by: Björn Töpel <bjorn@rivosinc.com>
Acked-by: Björn Töpel <bjorn@kernel.org>

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Björn Töpel]

Pu Lehui <pulehui@huaweicloud.com> writes:

> From: Pu Lehui <pulehui@huawei.com>
>
> Add necessary Zbb instructions introduced by [0] to reduce code size and
> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
> added to check whether the CPU supports Zbb instructions.
>
> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
> ---
>  arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>
> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
> index e30501b46f8f..51f6d214086f 100644
> --- a/arch/riscv/net/bpf_jit.h
> +++ b/arch/riscv/net/bpf_jit.h
> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>  	return IS_ENABLED(CONFIG_RISCV_ISA_C);
>  }
>  
> +static inline bool rvzbb_enabled(void)
> +{
> +	return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);

Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
for a kernel JIT compiler.

IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
Should it be enough to just have the run-time check? Should a kernel
built w/o Zbb be able to emit Zbb from the JIT?


Björn

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Pu Lehui]

On 2024/1/28 1:16, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
> 
>> From: Pu Lehui <pulehui@huawei.com>
>>
>> Add necessary Zbb instructions introduced by [0] to reduce code size and
>> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
>> added to check whether the CPU supports Zbb instructions.
>>
>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>> ---
>>   arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>>   1 file changed, 32 insertions(+)
>>
>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>> index e30501b46f8f..51f6d214086f 100644
>> --- a/arch/riscv/net/bpf_jit.h
>> +++ b/arch/riscv/net/bpf_jit.h
>> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>>   	return IS_ENABLED(CONFIG_RISCV_ISA_C);
>>   }
>>   
>> +static inline bool rvzbb_enabled(void)
>> +{
>> +	return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> 
> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
> for a kernel JIT compiler.
> 
> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
> Should it be enough to just have the run-time check? Should a kernel
> built w/o Zbb be able to emit Zbb from the JIT?
> 

Not enough, because riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) is a 
platform capability check, and the other one is a kernel image 
capability check. We can pass the check 
riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when 
CONFIG_RISCV_ISA_ZBB=n. And my local test prove it.

> 
> Björn

Re: Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Andrew Jones]

On Sat, Jan 27, 2024 at 06:16:41PM +0100, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
> 
> > From: Pu Lehui <pulehui@huawei.com>
> >
> > Add necessary Zbb instructions introduced by [0] to reduce code size and
> > improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
> > added to check whether the CPU supports Zbb instructions.
> >
> > Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
> > Signed-off-by: Pu Lehui <pulehui@huawei.com>
> > ---
> >  arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
> >  1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
> > index e30501b46f8f..51f6d214086f 100644
> > --- a/arch/riscv/net/bpf_jit.h
> > +++ b/arch/riscv/net/bpf_jit.h
> > @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
> >  	return IS_ENABLED(CONFIG_RISCV_ISA_C);
> >  }
> >  
> > +static inline bool rvzbb_enabled(void)
> > +{
> > +	return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> 
> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
> for a kernel JIT compiler.
> 
> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
> Should it be enough to just have the run-time check? Should a kernel
> built w/o Zbb be able to emit Zbb from the JIT?
>

My two cents (which might be worth less than two cents due to my lack of
BPF knowledge) is yes, the JIT should be allowed to emit Zbb instructions
even when the kernel is not built with a compiler which has done so. In
fact, we have insn-def.h for situations similar to this.

Thanks,
drew

Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:

On Mon, 15 Jan 2024 13:12:29 +0000 you wrote:
> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
> Meanwhile, adjust the code for unification and simplification. Tests
> test_bpf.ko and test_verifier have passed, as well as the relative
> testcases of test_progs*.
> 
> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
> 
> [...]

Here is the summary with links:
  - [RESEND,bpf-next,v3,1/6] riscv, bpf: Unify 32-bit sign-extension to emit_sextw
    https://git.kernel.org/bpf/bpf-next/c/e33758f7493c
  - [RESEND,bpf-next,v3,2/6] riscv, bpf: Unify 32-bit zero-extension to emit_zextw
    https://git.kernel.org/bpf/bpf-next/c/914c7a5ff18a
  - [RESEND,bpf-next,v3,3/6] riscv, bpf: Simplify sext and zext logics in branch instructions
    https://git.kernel.org/bpf/bpf-next/c/361db44c3c59
  - [RESEND,bpf-next,v3,4/6] riscv, bpf: Add necessary Zbb instructions
    https://git.kernel.org/bpf/bpf-next/c/647b93f65daa
  - [RESEND,bpf-next,v3,5/6] riscv, bpf: Optimize sign-extention mov insns with Zbb support
    https://git.kernel.org/bpf/bpf-next/c/519fb722bea0
  - [RESEND,bpf-next,v3,6/6] riscv, bpf: Optimize bswap insns with Zbb support
    https://git.kernel.org/bpf/bpf-next/c/06a33d024838

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Daniel Borkmann]

On 1/29/24 10:13 AM, Pu Lehui wrote:
> On 2024/1/28 1:16, Björn Töpel wrote:
>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>
>>> From: Pu Lehui <pulehui@huawei.com>
>>>
>>> Add necessary Zbb instructions introduced by [0] to reduce code size and
>>> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
>>> added to check whether the CPU supports Zbb instructions.
>>>
>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>> ---
>>>   arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>>>   1 file changed, 32 insertions(+)
>>>
>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>> index e30501b46f8f..51f6d214086f 100644
>>> --- a/arch/riscv/net/bpf_jit.h
>>> +++ b/arch/riscv/net/bpf_jit.h
>>> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>>>       return IS_ENABLED(CONFIG_RISCV_ISA_C);
>>>   }
>>> +static inline bool rvzbb_enabled(void)
>>> +{
>>> +    return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>
>> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
>> for a kernel JIT compiler.
>>
>> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
>> Should it be enough to just have the run-time check? Should a kernel
>> built w/o Zbb be able to emit Zbb from the JIT?
> 
> Not enough, because riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) is a platform capability check, and the other one is a kernel image capability check. We can pass the check riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when CONFIG_RISCV_ISA_ZBB=n. And my local test prove it.

So if I understand you correctly, only relying on the riscv_has_extension_likely(RISCV_ISA_EXT_ZBB)
part would not work - iow, the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) is mandatory here?

Thanks,
Daniel

P.s.: Given Bjorn's review and tests I took the series into bpf-next now. Thanks everyone!

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Pu Lehui]

On 2024/1/29 23:32, Daniel Borkmann wrote:
> On 1/29/24 10:13 AM, Pu Lehui wrote:
>> On 2024/1/28 1:16, Björn Töpel wrote:
>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>
>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>
>>>> Add necessary Zbb instructions introduced by [0] to reduce code size 
>>>> and
>>>> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
>>>> added to check whether the CPU supports Zbb instructions.
>>>>
>>>> Link: 
>>>> https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>>> ---
>>>>   arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>>>>   1 file changed, 32 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>>> index e30501b46f8f..51f6d214086f 100644
>>>> --- a/arch/riscv/net/bpf_jit.h
>>>> +++ b/arch/riscv/net/bpf_jit.h
>>>> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>>>>       return IS_ENABLED(CONFIG_RISCV_ISA_C);
>>>>   }
>>>> +static inline bool rvzbb_enabled(void)
>>>> +{
>>>> +    return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && 
>>>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>>
>>> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
>>> for a kernel JIT compiler.
>>>
>>> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
>>> Should it be enough to just have the run-time check? Should a kernel
>>> built w/o Zbb be able to emit Zbb from the JIT?
>>
>> Not enough, because riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) is a 
>> platform capability check, and the other one is a kernel image 
>> capability check. We can pass the check 
>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when 
>> CONFIG_RISCV_ISA_ZBB=n. And my local test prove it.
> 
> So if I understand you correctly, only relying on the 
> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB)
> part would not work - iow, the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) is 
> mandatory here?
> 

Yes, it should be IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && 
riscv_has_extension_likely(RISCV_ISA_EXT_ZBB).

> Thanks,
> Daniel
> 
> P.s.: Given Bjorn's review and tests I took the series into bpf-next 
> now. Thanks everyone!

Thanks Daniel and Björn

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Björn Töpel]

Daniel Borkmann <daniel@iogearbox.net> writes:

> On 1/29/24 10:13 AM, Pu Lehui wrote:
>> On 2024/1/28 1:16, Björn Töpel wrote:
>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>
>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>
>>>> Add necessary Zbb instructions introduced by [0] to reduce code size and
>>>> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
>>>> added to check whether the CPU supports Zbb instructions.
>>>>
>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>>> ---
>>>>   arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>>>>   1 file changed, 32 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>>> index e30501b46f8f..51f6d214086f 100644
>>>> --- a/arch/riscv/net/bpf_jit.h
>>>> +++ b/arch/riscv/net/bpf_jit.h
>>>> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>>>>       return IS_ENABLED(CONFIG_RISCV_ISA_C);
>>>>   }
>>>> +static inline bool rvzbb_enabled(void)
>>>> +{
>>>> +    return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>>
>>> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
>>> for a kernel JIT compiler.
>>>
>>> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
>>> Should it be enough to just have the run-time check? Should a kernel
>>> built w/o Zbb be able to emit Zbb from the JIT?
>> 
>> Not enough, because riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) is
>> a platform capability check, and the other one is a kernel image
>> capability check. We can pass the check
>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
>> CONFIG_RISCV_ISA_ZBB=n. And my local test prove it.

What I'm trying to say (and drew as well in the other reply) is that
"riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
CONFIG_RISCV_ISA_ZBB=n" should also make the JIT emit Zbb insns. The
platform check should be sufficient.

> So if I understand you correctly, only relying on the
> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) part would not work -
> iow, the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) is mandatory here?
>
> Thanks,
> Daniel
>
> P.s.: Given Bjorn's review and tests I took the series into bpf-next
> now. Thanks everyone!

Thanks! Yes, this is mainly a semantic discussion, and it can be further
relaxed later with a follow up -- if applicable.


Björn

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Pu Lehui]

On 2024/1/30 14:18, Björn Töpel wrote:
> Daniel Borkmann <daniel@iogearbox.net> writes:
> 
>> On 1/29/24 10:13 AM, Pu Lehui wrote:
>>> On 2024/1/28 1:16, Björn Töpel wrote:
>>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>>
>>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>>
>>>>> Add necessary Zbb instructions introduced by [0] to reduce code size and
>>>>> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
>>>>> added to check whether the CPU supports Zbb instructions.
>>>>>
>>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>>>> ---
>>>>>    arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>>>>>    1 file changed, 32 insertions(+)
>>>>>
>>>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>>>> index e30501b46f8f..51f6d214086f 100644
>>>>> --- a/arch/riscv/net/bpf_jit.h
>>>>> +++ b/arch/riscv/net/bpf_jit.h
>>>>> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>>>>>        return IS_ENABLED(CONFIG_RISCV_ISA_C);
>>>>>    }
>>>>> +static inline bool rvzbb_enabled(void)
>>>>> +{
>>>>> +    return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>>>
>>>> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
>>>> for a kernel JIT compiler.
>>>>
>>>> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
>>>> Should it be enough to just have the run-time check? Should a kernel
>>>> built w/o Zbb be able to emit Zbb from the JIT?
>>>
>>> Not enough, because riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) is
>>> a platform capability check, and the other one is a kernel image
>>> capability check. We can pass the check
>>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
>>> CONFIG_RISCV_ISA_ZBB=n. And my local test prove it.
> 
> What I'm trying to say (and drew as well in the other reply) is that
> "riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
> CONFIG_RISCV_ISA_ZBB=n" should also make the JIT emit Zbb insns. The
> platform check should be sufficient.

Ooh, this is really beyond my expectation. The test_progs can pass when 
with only platform check and it can recognize the zbb instructions. Now 
I know it. Sorry for misleading.🙁

Curious if CONFIG_RISCV_ISA_ZBB is still necessary?

> 
>> So if I understand you correctly, only relying on the
>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) part would not work -
>> iow, the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) is mandatory here?
>>
>> Thanks,
>> Daniel
>>
>> P.s.: Given Bjorn's review and tests I took the series into bpf-next
>> now. Thanks everyone!
> 
> Thanks! Yes, this is mainly a semantic discussion, and it can be further
> relaxed later with a follow up -- if applicable.
> 
> 
> Björn

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Björn Töpel]

Pu Lehui <pulehui@huawei.com> writes:

> On 2024/1/30 14:18, Björn Töpel wrote:
>> Daniel Borkmann <daniel@iogearbox.net> writes:
>> 
>>> On 1/29/24 10:13 AM, Pu Lehui wrote:
>>>> On 2024/1/28 1:16, Björn Töpel wrote:
>>>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>>>
>>>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>>>
>>>>>> Add necessary Zbb instructions introduced by [0] to reduce code size and
>>>>>> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
>>>>>> added to check whether the CPU supports Zbb instructions.
>>>>>>
>>>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>>>>> ---
>>>>>>    arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>>>>>>    1 file changed, 32 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>>>>> index e30501b46f8f..51f6d214086f 100644
>>>>>> --- a/arch/riscv/net/bpf_jit.h
>>>>>> +++ b/arch/riscv/net/bpf_jit.h
>>>>>> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>>>>>>        return IS_ENABLED(CONFIG_RISCV_ISA_C);
>>>>>>    }
>>>>>> +static inline bool rvzbb_enabled(void)
>>>>>> +{
>>>>>> +    return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>>>>
>>>>> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
>>>>> for a kernel JIT compiler.
>>>>>
>>>>> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
>>>>> Should it be enough to just have the run-time check? Should a kernel
>>>>> built w/o Zbb be able to emit Zbb from the JIT?
>>>>
>>>> Not enough, because riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) is
>>>> a platform capability check, and the other one is a kernel image
>>>> capability check. We can pass the check
>>>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
>>>> CONFIG_RISCV_ISA_ZBB=n. And my local test prove it.
>> 
>> What I'm trying to say (and drew as well in the other reply) is that
>> "riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
>> CONFIG_RISCV_ISA_ZBB=n" should also make the JIT emit Zbb insns. The
>> platform check should be sufficient.
>
> Ooh, this is really beyond my expectation. The test_progs can pass when 
> with only platform check and it can recognize the zbb instructions. Now 
> I know it. Sorry for misleading.🙁
>
> Curious if CONFIG_RISCV_ISA_ZBB is still necessary?

You don't need IS_ENABLED(CONFIG_RISCV_ISA_ZBB) for the JIT, but the
kernel needs it.

Feel free to follow up with a patch to remove it.


Cheers,
Björn

Re: [PATCH RESEND bpf-next v3 4/6] riscv, bpf: Add necessary Zbb instructions

[Pu Lehui]

On 2024/1/31 1:34, Björn Töpel wrote:
> Pu Lehui <pulehui@huawei.com> writes:
> 
>> On 2024/1/30 14:18, Björn Töpel wrote:
>>> Daniel Borkmann <daniel@iogearbox.net> writes:
>>>
>>>> On 1/29/24 10:13 AM, Pu Lehui wrote:
>>>>> On 2024/1/28 1:16, Björn Töpel wrote:
>>>>>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>>>>>
>>>>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>>>>
>>>>>>> Add necessary Zbb instructions introduced by [0] to reduce code size and
>>>>>>> improve performance of RV64 JIT. Meanwhile, a runtime deteted helper is
>>>>>>> added to check whether the CPU supports Zbb instructions.
>>>>>>>
>>>>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>>>>>> ---
>>>>>>>     arch/riscv/net/bpf_jit.h | 32 ++++++++++++++++++++++++++++++++
>>>>>>>     1 file changed, 32 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>>>>>> index e30501b46f8f..51f6d214086f 100644
>>>>>>> --- a/arch/riscv/net/bpf_jit.h
>>>>>>> +++ b/arch/riscv/net/bpf_jit.h
>>>>>>> @@ -18,6 +18,11 @@ static inline bool rvc_enabled(void)
>>>>>>>         return IS_ENABLED(CONFIG_RISCV_ISA_C);
>>>>>>>     }
>>>>>>> +static inline bool rvzbb_enabled(void)
>>>>>>> +{
>>>>>>> +    return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>>>>>
>>>>>> Hmm, I'm thinking about the IS_ENABLED(CONFIG_RISCV_ISA_ZBB) semantics
>>>>>> for a kernel JIT compiler.
>>>>>>
>>>>>> IS_ENABLED(CONFIG_RISCV_ISA_ZBB) affects the kernel compiler flags.
>>>>>> Should it be enough to just have the run-time check? Should a kernel
>>>>>> built w/o Zbb be able to emit Zbb from the JIT?
>>>>>
>>>>> Not enough, because riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) is
>>>>> a platform capability check, and the other one is a kernel image
>>>>> capability check. We can pass the check
>>>>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
>>>>> CONFIG_RISCV_ISA_ZBB=n. And my local test prove it.
>>>
>>> What I'm trying to say (and drew as well in the other reply) is that
>>> "riscv_has_extension_likely(RISCV_ISA_EXT_ZBB) when
>>> CONFIG_RISCV_ISA_ZBB=n" should also make the JIT emit Zbb insns. The
>>> platform check should be sufficient.
>>
>> Ooh, this is really beyond my expectation. The test_progs can pass when
>> with only platform check and it can recognize the zbb instructions. Now
>> I know it. Sorry for misleading.🙁
>>
>> Curious if CONFIG_RISCV_ISA_ZBB is still necessary?
> 
> You don't need IS_ENABLED(CONFIG_RISCV_ISA_ZBB) for the JIT, but the
> kernel needs it.
> 
> Feel free to follow up with a patch to remove it.
> 

Maybe we can implement more extensions about bitmanip.

> 
> Cheers,
> Björn