linux-kernel - Re: [PATCH v5 0/6] Provide a fraemework for RISC-V ISA extensions

Open Source and information security mailing list archives

Message-ID: <CAK9=C2WZCp2aKnFTVN0iDqDxVgV6WMFzsM+a9a1Q8Go_n6iMkw@mail.gmail.com>
Date:   Fri, 11 Mar 2022 18:40:28 +0530
From:   Anup Patel <apatel@...tanamicro.com>
To:     Nick Kossifidis <mick@....forth.gr>
Cc:     Atish Kumar Patra <atishp@...osinc.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        Albert Ou <aou@...s.berkeley.edu>,
        Atish Patra <atishp@...shpatra.org>,
        Anup Patel <anup@...infault.org>,
        Damien Le Moal <damien.lemoal@....com>,
        devicetree <devicetree@...r.kernel.org>,
        Jisheng Zhang <jszhang@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Rob Herring <robh+dt@...nel.org>,
        Philipp Tomsich <philipp.tomsich@...ll.eu>
Subject: Re: [PATCH v5 0/6] Provide a fraemework for RISC-V ISA extensions

On Fri, Mar 11, 2022 at 6:13 PM Nick Kossifidis <mick@....forth.gr> wrote:
>
> Στις 2022-03-11 02:21, Atish Kumar Patra έγραψε:
> > On Thu, Mar 10, 2022 at 3:50 PM Palmer Dabbelt <palmer@...belt.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 improvement
> >> > series[1]. I have fixed few bugs and improved comments from that series
> >> > (PATCH1-3). I have not used PATCH 4 from that series as we are not using
> >> > ISA extension versioning as of now. We can add that later if required.
> >> >
> >> > 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 extensions.
> >> >
> >> > PATCH 6 improves the /proc/cpuinfo interface for the available ISA extensions
> >> > 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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives