From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 79F5ECD11DD for ; Fri, 29 Mar 2024 10:06:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Y5f3QwVg1Td8a/Uf7zgDMAFKw5B3FLuLmcsgMOmZs6o=; b=CJZ8AJgApsdoLe BNJW1W+5tV4QUtCzYJEQNA7zJAuING6boKDl1CIzu00aGYlhffyLc29WMWZz4IMXplQB1UhRYVTJ8 PRQknlyxa+7UgePXPj+zqw3PAzBsOFIXDKmv4twVx7GI8fZU0TlANzw/zl250gfwAIJC0hsrJ1Ndb izqneQq2Xz5keOKiIP4zj2vf18lZcUnvdk0cqQzmkxti6C80fKgFltSGsKIbRs5tHKv4V45pld6kQ kQiXm+fX4Gi9VuVW+DlBTS/YZp8FhWLNy2rjiG99xcKqCH4D9/MshLOaiTLxy2oB3bdcKD7IodN5Y sEVYwdlTw2dhSieY1yuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rq97b-0000000HaJg-03Z1; Fri, 29 Mar 2024 10:06:03 +0000 Received: from [45.249.212.56] (helo=dggsgout12.his.huawei.com) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rq97W-0000000HaIl-2UeJ for linux-riscv@lists.infradead.org; Fri, 29 Mar 2024 10:06:01 +0000 Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4V5bdJ4rKDz4f3knR for ; Fri, 29 Mar 2024 18:05:40 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id F3B501A0232 for ; Fri, 29 Mar 2024 18:05:46 +0800 (CST) Received: from [10.67.109.184] (unknown [10.67.109.184]) by APP1 (Coremail) with SMTP id cCh0CgCXZg91kgZmxne1IQ--.1768S2; Fri, 29 Mar 2024 18:05:43 +0800 (CST) Message-ID: Date: Fri, 29 Mar 2024 18:05:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions Content-Language: en-US To: Stefan O'Rear , Conor Dooley Cc: bpf@vger.kernel.org, linux-riscv@lists.infradead.org, netdev@vger.kernel.org, =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Mykola Lysenko , Manu Bretelle , Pu Lehui References: <20240328124916.293173-1-pulehui@huaweicloud.com> <20240328124916.293173-3-pulehui@huaweicloud.com> <3ed9fe94-2610-41eb-8a00-a9f37fcf2b1a@app.fastmail.com> <20240328-ferocity-repose-c554f75a676c@spud> From: Pu Lehui In-Reply-To: <20240328-ferocity-repose-c554f75a676c@spud> X-CM-TRANSID: cCh0CgCXZg91kgZmxne1IQ--.1768S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJF43GrWDCry7Wr1rZr1rXrb_yoW5tF47pa 10kF1qka1DJa4Ik392qF18Wr1YvF4rKr43Jrn8J348A34jqrW2qF1kKa15uF1DXryrGr1j qr4UKF17u34DZFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxAIw28IcxkI 7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6x AIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU13rcDUUUUU== X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240329_030559_108985_AB9A928B X-CRM114-Status: GOOD ( 26.32 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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 >>> >>> 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? Link: https://lore.kernel.org/bpf/20240129-d06c79a17a5091b3403fc5b6@orel/ [0] >> >> If BPF needs to become an exception (why?), this should be mentioned in >> Kconfig. > > And in the commit message. On one hand I think this could be a reasonable > thing to do in bpf as it is acting as a jit here, and doesn't actually > need the alternatives that we are using elsewhere to enable the > optimisations nor the compiler support. On the other the intention of > that kconfig option is to control optimisations like rvzbb_enabled() > gates, so this is gonna need a proper justification as to > > As I said on IRC to you earlier, I think the Kconfig options here are in > need of a bit of a spring cleaning - they should be modified to explain > their individual purposes, be that enabling optimisations in the kernel > or being required for userspace. I'll try to send a patch for that if > I remember tomorrow. > > Thanks, > Conor. > >>> Signed-off-by: Pu Lehui >>> --- >>> arch/riscv/net/bpf_jit.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h >>> index 5fc374ed98ea..bcf109b88df5 100644 >>> --- a/arch/riscv/net/bpf_jit.h >>> +++ b/arch/riscv/net/bpf_jit.h >>> @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void) >>> >>> static inline bool rvzbb_enabled(void) >>> { >>> - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && >>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB); >>> + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB); >>> } >>> >>> enum { >>> -- >>> 2.34.1 >>> >>> >>> _______________________________________________ >>> linux-riscv mailing list >>> linux-riscv@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-riscv >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B3593D0D2; Fri, 29 Mar 2024 10:05:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711706760; cv=none; b=ioqasBo9rTaOfIXUPiWtCmp5fIzzRJHFTi9HErmR3BDU5tqG1yt8N7mAoYOylGf8UUf7JcbBcljNx+gARx+ijyKfUzZhxrShT5DaE91kV3PExCK5ZuqfyBmlfEXuujNea8ODV0bfruoc1nFRFHGL62cvHNAsnBUErdgZZOnVd9A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711706760; c=relaxed/simple; bh=aqgWLAlXcnotGgSYgY9TrilUarV/SJyTu/HI/BjiZp8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EOzdht9AS3lP1BnviCQvWSOxRwFml7+mLwiPqWI4mPC8wWuMn4L9ASFZxw656zLlfHFxIzjTnGJ3v8ghyjBert95PoftbBJPglhyXoim4jrD0kkpLMjMmYiw99T1vqK+t3GIu9Mq7i7cRv9H0o3zwMYwPqpg+5w8s8qs3maIEvY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4V5bdG5nCfz4f3mHL; Fri, 29 Mar 2024 18:05:38 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 07B5C1A0172; Fri, 29 Mar 2024 18:05:47 +0800 (CST) Received: from [10.67.109.184] (unknown [10.67.109.184]) by APP1 (Coremail) with SMTP id cCh0CgCXZg91kgZmxne1IQ--.1768S2; Fri, 29 Mar 2024 18:05:43 +0800 (CST) Message-ID: Date: Fri, 29 Mar 2024 18:05:41 +0800 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions Content-Language: en-US To: Stefan O'Rear , Conor Dooley Cc: bpf@vger.kernel.org, linux-riscv@lists.infradead.org, netdev@vger.kernel.org, =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Mykola Lysenko , Manu Bretelle , Pu Lehui References: <20240328124916.293173-1-pulehui@huaweicloud.com> <20240328124916.293173-3-pulehui@huaweicloud.com> <3ed9fe94-2610-41eb-8a00-a9f37fcf2b1a@app.fastmail.com> <20240328-ferocity-repose-c554f75a676c@spud> From: Pu Lehui In-Reply-To: <20240328-ferocity-repose-c554f75a676c@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:cCh0CgCXZg91kgZmxne1IQ--.1768S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJF43GrWDCry7Wr1rZr1rXrb_yoW5tF47pa 10kF1qka1DJa4Ik392qF18Wr1YvF4rKr43Jrn8J348A34jqrW2qF1kKa15uF1DXryrGr1j qr4UKF17u34DZFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxAIw28IcxkI 7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6x AIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU13rcDUUUUU== X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/ 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 >>> >>> 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? Link: https://lore.kernel.org/bpf/20240129-d06c79a17a5091b3403fc5b6@orel/ [0] >> >> If BPF needs to become an exception (why?), this should be mentioned in >> Kconfig. > > And in the commit message. On one hand I think this could be a reasonable > thing to do in bpf as it is acting as a jit here, and doesn't actually > need the alternatives that we are using elsewhere to enable the > optimisations nor the compiler support. On the other the intention of > that kconfig option is to control optimisations like rvzbb_enabled() > gates, so this is gonna need a proper justification as to > > As I said on IRC to you earlier, I think the Kconfig options here are in > need of a bit of a spring cleaning - they should be modified to explain > their individual purposes, be that enabling optimisations in the kernel > or being required for userspace. I'll try to send a patch for that if > I remember tomorrow. > > Thanks, > Conor. > >>> Signed-off-by: Pu Lehui >>> --- >>> arch/riscv/net/bpf_jit.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h >>> index 5fc374ed98ea..bcf109b88df5 100644 >>> --- a/arch/riscv/net/bpf_jit.h >>> +++ b/arch/riscv/net/bpf_jit.h >>> @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void) >>> >>> static inline bool rvzbb_enabled(void) >>> { >>> - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && >>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB); >>> + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB); >>> } >>> >>> enum { >>> -- >>> 2.34.1 >>> >>> >>> _______________________________________________ >>> linux-riscv mailing list >>> linux-riscv@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-riscv >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv