Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <20231017131456.2053396-1-cleger@rivosinc.com> <20231017131456.2053396-6-cleger@rivosinc.com>
 <DA8B4610-D514-4733-B875-C247FFCCC7AA@sifive.com> <af785f0f-9de7-4548-9cdb-f392cde1cc2b@rivosinc.com>
In-Reply-To: <af785f0f-9de7-4548-9cdb-f392cde1cc2b@rivosinc.com>
From:   Evan Green <evan@rivosinc.com>
Date:   Wed, 18 Oct 2023 10:26:34 -0700
Message-ID: <CALs-HstEBt-ntCcETa9YwS6On3nGyoEc2p7R-gaBLG9+aFJL5w@mail.gmail.com>
Subject: Re: [PATCH v2 05/19] riscv: add ISA extension parsing for vector
 crypto extensions
To:     =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <cleger@rivosinc.com>
Cc:     Jerry Shih <jerry.shih@sifive.com>,
        linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        Palmer Dabbelt <palmer@rivosinc.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Jonathan Corbet <corbet@lwn.net>,
        Andrew Jones <ajones@ventanamicro.com>,
        Conor Dooley <conor@kernel.org>,
        Samuel Ortiz <sameo@rivosinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Oct 18, 2023 at 5:53=E2=80=AFAM Cl=C3=A9ment L=C3=A9ger <cleger@riv=
osinc.com> wrote:
>
>
>
> On 18/10/2023 03:45, Jerry Shih wrote:
> > On Oct 17, 2023, at 21:14, Cl=C3=A9ment L=C3=A9ger <cleger@rivosinc.com=
> 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 bundled=
 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.

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).

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.

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.

-Evan