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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1859467.Zi3Bu27KEa@diego>
Date:   Thu, 03 Feb 2022 14:56:43 +0100
From:   Heiko Stübner <heiko@...ech.de>
To:     Palmer Dabbelt <palmer@...belt.com>,
        Tsukasa OI <research_trasio@....a4lg.com>,
        linux-riscv@...ts.infradead.org
Cc:     "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        Atish Patra <atishp@...osinc.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        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>,
        Atish Patra <atishp@...shpatra.org>
Subject: Re: [PATCH v1 0/2] Provide a fraemework for RISC-V ISA extensions

Hi Atish,

Am Samstag, 8. Januar 2022, 03:24:12 CET schrieb Atish Patra:
> On Fri, Jan 7, 2022 at 1:58 PM Palmer Dabbelt <palmer@...belt.com> wrote:
> >
> > On Fri, 24 Dec 2021 13:16:30 PST (-0800), atishp@...shpatra.org wrote:
> > > This series implements a generic framework to parse multi-letter ISA
> > > extensions. It introduces a new DT node that can be under /cpus or
> > > individual cpu depends on the platforms with homogeneous or heterogeneous
> > > harts. This version of the series only allows adds support for homogeneous
> > > harts as there are no platforms with heterogeneous harts yet. However,
> > > the DT binding allows both.
> > >
> > > The patch also indicates the user space about 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           : rv64imafdcsu
> > > isa-ext               : sstc,sscofpmf
> > > mmu           : sv48
> >
> > IMO this is the wrong way to go.  I get that the ISA string is very
> > complicated to parse, but we've tried to come up with other
> > representations of this we've ended up having that interface break when
> > the ISA string rules eventually change.  We should just stick to the ISA
> > string for these interfaces, as that's at least something everyone can
> > agree on because they're defined by the spec.
> >
> 
> Fair enough.
> 
> > That said, we should add the spec versions into this interface.  At
> > least the user spec version is relevant here, but given that we're
> > passing through some other priv-level details we might as well pass that
> > though too.
> >
> 
> Tsukasa already has a version that extends the isa string parsing for
> multi-letter extensions
> and versions parsing. We just need to add the ISA bitmap support on top of it.
> 
> I will coordinate with Tsukasa to have a complete framework based on
> string parsing.
> It would be good to have this series asap as all other series  (perf,
> svpbmt) will rely on it.

out of curiosity, did this go anywhere yet in terms of the coordinated
approach you wrote about?

Thanks
Heiko