| Message ID | 20240115131235.2914289-5-pulehui@huaweicloud.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | Zbb support and code simplification for RV64 JIT | expand |
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
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
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
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!
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
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
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.
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.
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.
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. *