Received: by 2002:a05:7412:f690:b0:e2:908c:2ebd with SMTP id ej16csp437000rdb; Thu, 19 Oct 2023 08:33:45 -0700 (PDT) X-Google-Smtp-Source: AGHT+IESfH/Up2c+uGEANTdXMN0Mkn8oxHFSELCeaeEQ0ldLcqZJFPv9y5jd/Mq1wDpDLLJ7W0jC X-Received: by 2002:a05:6358:f909:b0:168:ae89:267 with SMTP id kv9-20020a056358f90900b00168ae890267mr555803rwb.0.1697729625170; Thu, 19 Oct 2023 08:33:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697729625; cv=none; d=google.com; s=arc-20160816; b=IOIxzTVJvqsVEVbiKP1QxXryEICYRoTGgXx5WS1rAsdQfcLj/NOwJcP7HzRXBt+kTY pF9dvTZq0BCaoEQGb+2AaYZds6dNH3+vwEMRmFD9znicuK9BTx7KY3XbtddPP6N3ZFOX XHvPrCjTrKth49zk5qj1xaiSVh5Xtud2YveoOXMryezceFVwon82bfOhMoHKSYVXk6Mf uZJpFAdAylcqUBEc494jM2wQlVDUV30J9FXEXYtDgjEC4uAKy6l0M2bihXByKwRWqefK dN/JPkMt/yhJAVV6/FbQKCdVhhWGeXMO3qB8O1PoEcjX1Wx7TMiAV0L0VPDU3HXVobIW Np/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=l2Eaq2dFpXIOcz2Dj0hvTyJN7WH6nFNEDYvGETSR4SI=; fh=WBiwBE4nVjliJzFmkGduuKE9kADNAPqCoTXVXe9SKI8=; b=H9eAPtlsztfoK7Sx0ei3XI6xh+fCZRG3M5hAD1xcC1+KxxDqn9/7z6dk5SVa3w+1HP wDvfabYKS63WYQbq94C7PT7IpYCGzibE0iQVbnagIExoYGqX8LLEcpmE6+6dXVtvJGk7 HHeswqN6Mis5jYHH/fv3JkxuRyEyUxXZm6cnPd3Jwz2b3SwfddpqtxGG5ryoRzlK6mks gtXtsOnuHng6c0ycLD70+KaKiEibWRPaVcMHRwhj//rHkbT/ahxJHWYnFIodVLFa/0Fa EM4YOQjWrYYBFKNHvhOf7ejN7bSZ/m8T1JwJsFQ2IOHBFcOvyHTLfGqznbjqT1MR0yEx eb5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=N97pbG5e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id y19-20020aa78f33000000b0069023e4bcb4si2716883pfr.114.2023.10.19.08.33.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Oct 2023 08:33:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=N97pbG5e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 3A48082516EA; Thu, 19 Oct 2023 08:33:41 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346316AbjJSPdX (ORCPT + 99 others); Thu, 19 Oct 2023 11:33:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346308AbjJSPdT (ORCPT ); Thu, 19 Oct 2023 11:33:19 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2892F18F for ; Thu, 19 Oct 2023 08:33:17 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C5FDC433C8; Thu, 19 Oct 2023 15:33:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697729597; bh=HwwRNCwT8BYB1JzATrYA1vnmNd3NZ1gsX/BTgIeQxys=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=N97pbG5eH+rIsR4tEcQlulJ2kgrWW2CryHjiZOTPl5Li7NNuRFr7bLP5lcqz06mb8 I0yq83Oz7HW3+xQj2QxqHqRZvb7UvfQQJF1JLaAWhqjApWcvYt5CgteXF7OEntP3yB e+/sKHHlXiqrMgRmA4oy/muxqBC44EUPh76dQMzwrY0Q2fZCNuCkwhNoGlaDwqFvUj sE7xiMKRnN68hE7eoJDiEVZFu6KO0BWkPpeMdESqXx22QsqFKg/vGJYnu+DVeb0iO3 JQQygDm6uKa9lDbcIXYvBau0PjJay6LR1B6BRuy4WnGAk+j+4F0fAkFEuO55Zb2lfA CeA7SsZiSU+9A== Date: Thu, 19 Oct 2023 16:33:12 +0100 From: Conor Dooley To: =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= Cc: Evan Green , Jerry Shih , linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Palmer Dabbelt , Paul Walmsley , Rob Herring , Krzysztof Kozlowski , Albert Ou , Jonathan Corbet , Andrew Jones , Samuel Ortiz Subject: Re: [PATCH v2 05/19] riscv: add ISA extension parsing for vector crypto extensions Message-ID: <20231019-nuclear-vista-ef3e0b9bef71@spud> References: <20231017131456.2053396-1-cleger@rivosinc.com> <20231017131456.2053396-6-cleger@rivosinc.com> <7626f978-e9ea-4f8f-b814-aeac02bd3712@rivosinc.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VdNzOK6fe6sE2V7+" Content-Disposition: inline In-Reply-To: <7626f978-e9ea-4f8f-b814-aeac02bd3712@rivosinc.com> X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 19 Oct 2023 08:33:41 -0700 (PDT) --VdNzOK6fe6sE2V7+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 19, 2023 at 11:35:59AM +0200, Cl=C3=A9ment L=C3=A9ger wrote: >=20 >=20 > On 18/10/2023 19:26, Evan Green wrote: > > On Wed, Oct 18, 2023 at 5:53=E2=80=AFAM Cl=C3=A9ment L=C3=A9ger wrote: > >> > >> > >> > >> On 18/10/2023 03:45, Jerry Shih wrote: > >>> On Oct 17, 2023, at 21:14, Cl=C3=A9ment L=C3=A9ger wrote: > >>>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[]= =3D { > >>>> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > >>>> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > >>>> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > >>>> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB), > >>>> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC), > >>>> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB), > >>> > >>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundl= ed with `Zvbb`. > >> > >> Hi Jerry, > >> > >> Thanks for catching this, I think some other extensions will fall in > >> this category as well then (Zvknha/Zvknhb). I will verify that. > >=20 > > The bundling mechanism works well when an extension is a pure lasso > > around other extensions. We'd have to tweak that code if we wanted to > > support cases like this, where the extension is a superset of others, > > but also contains loose change not present anywhere else (and > > therefore also needs to stand as a separate bit). >=20 > For Zvbb and Zvknhb, I used the following code: >=20 > static const unsigned int riscv_zvbb_bundled_exts[] =3D { > RISCV_ISA_EXT_ZVKB, > RISCV_ISA_EXT_ZVBB > }; >=20 > static const unsigned int riscv_zvknhb_bundled_exts[] =3D { > RISCV_ISA_EXT_ZVKNHA, > RISCV_ISA_EXT_ZVKNHB > }; >=20 > Which correctly results in both extension (superset + base set) being > enabled when only one is set. Is there something that I'm missing ? >=20 > >=20 > > IMO, decomposing "pure" bundles makes sense since otherwise usermode > > would have to query multiple distinct bitmaps that meant the same > > thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or > > maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But > > when an extension is a superset that also contains loose change, there > > really aren't two equivalent bitmasks, each bit adds something new. >=20 > Agreed but if a system only report ZVBB for instance and the user wants > ZVKB, then it is clear that ZVKB should be reported as well I guess. So > in the end, it works much like "bundle" extension, just that the bundle > is actually a "real" ISA extension by itself. >=20 > Cl=C3=A9ment >=20 > >=20 > > There's an argument to be made for still turning on the containing > > extensions to cover for silly ISA strings (eg ISA strings that > > advertise the superset but fail to advertise the containing > > extensions). We can decide if we want to work that hard to cover > > hypothetical broken ISA strings now, or wait until they show up. > > Personally I would wait until something broken shows up. But others > > may feel differently. I'm not really sure that those are "silly" ISA strings. People are going to do it that way because it is much easier than spelling out 5 dozen sub-components, and it is pretty inevitable that subsets will be introduced in the future for extensions we currently have. IMO, it's perfectly valid to say you have the supersets and not spell out all the subcomponents. --VdNzOK6fe6sE2V7+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZTFMOAAKCRB4tDGHoIJi 0jJxAQDXlhaCx8sNyUh8SSBPQepeS21XzSfsPqfo0fiwFpQb7wD/QhyzMzwWfC/1 nl0r8JLAMrkerLCK3Mpf0dfHXirH+Ag= =NsYQ -----END PGP SIGNATURE----- --VdNzOK6fe6sE2V7+--