Pu Lehui <pulehui@xxxxxxxxxxxxxxx> writes: > On 2024/3/29 6:07, Conor Dooley wrote: >> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote: >>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote: >>>> From: Pu Lehui <pulehui@xxxxxxxxxx> >>>> >>>> This patch relaxes the restrictions on the Zbb instructions. The hardware >>>> is capable of recognizing the Zbb instructions independently, eliminating >>>> the need for reliance on kernel compile configurations. >>> >>> This doesn't make sense to me. >> >> It doesn't make sense to me either. Of course the hardware's capability >> to understand an instruction is independent of whether or not a >> toolchain is capable of actually emitting the instruction. >> >>> RISCV_ISA_ZBB is defined as: >>> >>> Adds support to dynamically detect the presence of the ZBB >>> extension (basic bit manipulation) and enable its usage. >>> >>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts >>> to detect Zbb at runtime. It is mostly relevant for code size reduction, >>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled() >>> checks can be constant-folded. > > Thanks for review. My initial thought was the same as yours, but after > discussions [0] and test verifications, the hardware can indeed > recognize the zbb instruction even if the kernel has not enabled > CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to > emit zbb instruction here. Maybe is_hw_zbb_capable() will be better? I still think Lehui's patch is correct; Building a kernel that can boot on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in the kernel proper, and iff Zbb is available at run-time the BPF JIT will emit Zbb. For these kind of optimizations, (IMO) it's better to let the BPF JIT decide at run-time. Björn
