Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220222204811.2281949-1-atishp@rivosinc.com> <mhng-4593ea1e-503d-47df-8e55-d2ef06f01518@palmer-ri-x1c9>
 <CAHBxVyHaFk6mx_uTUcOG1d+XGokT_-Y3_Y1kVJixAnGGmLjAxg@mail.gmail.com> <d8d4fedad13ef063b672aadfe2ee0aff@mailhost.ics.forth.gr>
In-Reply-To: <d8d4fedad13ef063b672aadfe2ee0aff@mailhost.ics.forth.gr>
From:   Anup Patel <apatel@ventanamicro.com>
Date:   Fri, 11 Mar 2022 18:40:28 +0530
Message-ID: <CAK9=C2WZCp2aKnFTVN0iDqDxVgV6WMFzsM+a9a1Q8Go_n6iMkw@mail.gmail.com>
Subject: Re: [PATCH v5 0/6] Provide a fraemework for RISC-V ISA extensions
To:     Nick Kossifidis <mick@ics.forth.gr>
Cc:     Atish Kumar Patra <atishp@rivosinc.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Atish Patra <atishp@atishpatra.org>,
        Anup Patel <anup@brainfault.org>,
        Damien Le Moal <damien.lemoal@wdc.com>,
        devicetree <devicetree@vger.kernel.org>,
        Jisheng Zhang <jszhang@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Rob Herring <robh+dt@kernel.org>,
        Philipp Tomsich <philipp.tomsich@vrull.eu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Mar 11, 2022 at 6:13 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> =CE=A3=CF=84=CE=B9=CF=82 2022-03-11 02:21, Atish Kumar Patra =CE=AD=CE=B3=
=CF=81=CE=B1=CF=88=CE=B5:
> > On Thu, Mar 10, 2022 at 3:50 PM Palmer Dabbelt <palmer@dabbelt.com>
> > wrote:
> >>
> >> On Tue, 22 Feb 2022 12:48:05 PST (-0800), Atish Patra wrote:
> >> > This series implements a generic framework to parse multi-letter ISA
> >> > extensions. This series is based on Tsukasa's v3 isa extension impro=
vement
> >> > series[1]. I have fixed few bugs and improved comments from that ser=
ies
> >> > (PATCH1-3). I have not used PATCH 4 from that series as we are not u=
sing
> >> > ISA extension versioning as of now. We can add that later if require=
d.
> >> >
> >> > PATCH 4 allows the probing of multi-letter extensions via a macro.
> >> > It continues to use the common isa extensions between all the harts.
> >> > Thus hetergenous hart systems will only see the common ISA extension=
s.
> >> >
> >> > PATCH 6 improves the /proc/cpuinfo interface for the available ISA e=
xtensions
> >> > via /proc/cpuinfo.
> >> >
> >> > Here is the example output of /proc/cpuinfo:
> >> > (with debug patches in Qemu and Linux kernel)
> >> >
> >> > # cat /proc/cpuinfo
> >> > processor     : 0
> >> > hart          : 0
> >> > isa           : rv64imafdch
> >> > isa-ext               : svpbmt svnapot svinval
> >>
> >> I know it might seem a bit pedantic, but I really don't want to
> >> introduce a new format for encoding ISA extensions -- doubly so if
> >> this
> >> is the only way we're giving this info to userspace, as then we're
> >> just
> >> asking folks to turn this into a defacto ABI.  Every time we try to do
> >> something that's sort of like an ISA string but not exactly what's in
> >> the spec we end up getting burned, and while I don't see a specific
> >> way
> >
> > I agree that this is an ABI change/improvement which is impossible to
> > modify later.
> > However, this is a Linux specific ABI. Do you think the RISC-V spec
> > will ever say anything about how /proc/cpuinfo is shown to the user ?
> >
>
> Actually there was a discussion on chairs at some point on how isa
> extensions will be represented as a single string. If I recall correctly
> they wanted a way to compare features between implementations so this
> was something the user should be able to read as well. I'm ccing Philipp
> from the Software HC in case he has more details on this.
>
> I also believe we need to discuss this a bit further, also I thought we
> agreed that having everything as a single string (riscv-isa) on the
> device tree doesn't scale, there were some other suggestions regarding
> for example mmu extensions being declared inside an mmu sub-node etc.
> This patch series will not only make it hard to change /proc/cpuinfo
> output in the future, but also establishes a device-tree binding for all
> isa extensions through the riscv-isa string that we also won't be able
> to modify later on.

Initially we can just follow the ISA string approach because this
is what RISC-V unpric spec defines.

Specifying ISA extensions via DT or ACPI, can be incrementally
done in future.

We have a lot of patches (Svpbmt, Sstc, Scofpmf, Zcboxyz, etc)
blocked because we don't have a way to detect multi-letter
extensions in Linux.

Regards,
Anup

>
> Regards,
> Nick
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv