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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Subject: Re: [PATCH v2 2/3] dt-bindings: riscv: Add Svadu Entry
From:   Jessica Clarke <jrtc27@jrtc27.com>
In-Reply-To: <d141062b-e3e0-45ce-bc61-3404417c7d7c@app.fastmail.com>
Date:   Wed, 27 Sep 2023 19:44:32 +0100
Cc:     Yong-Xuan Wang <yongxuan.wang@sifive.com>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        kvm-riscv@lists.infradead.org,
        Greentime Hu <greentime.hu@sifive.com>,
        Vincent Chen <vincent.chen@sifive.com>,
        Jinyu Tang <tjytimi@163.com>, Alexandre Ghiti <alex@ghiti.fr>,
        Conor Dooley <conor@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, Stefan O'Rear <sorear@fastmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <55289FD5-55F7-4EE6-BBCC-933B32770A95@jrtc27.com>
References: <20230922085701.3164-1-yongxuan.wang@sifive.com>
 <20230922085701.3164-3-yongxuan.wang@sifive.com>
 <d141062b-e3e0-45ce-bc61-3404417c7d7c@app.fastmail.com>
To:     LKML <linux-kernel@vger.kernel.org>
Precedence: bulk

On 27 Sep 2023, at 18:24, Stefan O'Rear <sorear@fastmail.com> wrote:
>=20
> On Fri, Sep 22, 2023, at 4:56 AM, Yong-Xuan Wang wrote:
>> Add an entry for the Svadu extension to the riscv,isa-extensions =
property.
>>=20
>> Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
>> ---
>> Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>=20
>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml=20=

>> b/Documentation/devicetree/bindings/riscv/extensions.yaml
>> index cc1f546fdbdc..b5a0aed0165b 100644
>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>> @@ -147,6 +147,12 @@ properties:
>>             ratified at commit 3f9ed34 ("Add ability to manually=20
>> trigger
>>             workflow. (#2)") of riscv-time-compare.
>>=20
>> +        - const: svadu
>> +          description: |
>> +            The standard Svadu supervisor-level extension for =
hardware updating
>> +            of PTE A/D bits as frozen at commit b65e07c ("move to =
Frozen
>> +            state") of riscv-svadu.
>> +
>=20
> This is incomplete without a specification of the behavior of the HADE =
bit implied
> by svadu being present.
>=20
> The ratified RVA20 requires page table accesses with A/D =3D 0 to =
trap, in other
> words HADE =3D 0 for RVA20 conformance.  If we are serious about =
compatibility,
> I think that we need platforms to be able to conform to both RVA20 and =
RVA23,
> which requires HADE =3D 0 at kernel entry with a SBI call to set HADE =
=3D 1.  For
> the same reason KVM should probably default to HADE =3D 0 so that the =
default
> configuration remains conformant to RVA20.

I=E2=80=99ve filed https://github.com/riscv/riscv-svadu/issues/21 to =
track this
broken ISA design, as discussed on IRC.

As a FreeBSD RISC-V developer, and sometime reviewer of Linux RISC-V
patches, this is a NAK from me for this ISA design. Which does beg the
question of how much sense the current RISC-V processes make, given for
freezing a spec you just need to send out the relevant RFC patches,
they don=E2=80=99t actually need to have any review from the project in
question that says it=E2=80=99s a sensible design, instead treating that =
as
part of the public review period, where it=E2=80=99s much harder to
fundamentally change the spec, despite being the first time most people
see it or take it seriously as a thing to look at. In my opinion there
is a serious need for knowledgeable people on the software side to
review the ISA extension and its interaction with software *before* it
can be frozen so that these things can be fixed. And of course, if they
do get fixed during/after public review, what good is the frozen state
anyway, because a spec that changes is not very frozen.

But I=E2=80=99m probably preaching to the choir here about RISC-V =
processes
being unfit for purpose.

Jess

>>         - const: svinval
>>           description:
>>             The standard Svinval supervisor-level extension for =
fine-grained
>> --=20
>> 2.17.1
>>=20
>>=20
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>=20
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv