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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 07 Jan 2022 13:58:11 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     atishp@...shpatra.org
CC:     linux-kernel@...r.kernel.org, Atish Patra <atishp@...osinc.com>,
        aou@...s.berkeley.edu, atishp@...shpatra.org, anup@...infault.org,
        damien.lemoal@....com, devicetree@...r.kernel.org,
        jszhang@...nel.org, krzysztof.kozlowski@...onical.com,
        linux-riscv@...ts.infradead.org,
        Paul Walmsley <paul.walmsley@...ive.com>, robh+dt@...nel.org
Subject:     Re: [PATCH v1 0/2] Provide a fraemework for RISC-V ISA extensions 

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.

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.

> processor	: 1
> hart		: 1
> isa		: rv64imafdcsu
> isa-ext		: sstc,sscofpmf
> mmu		: sv48
>
> processor	: 2
> hart		: 2
> isa		: rv64imafdcsu
> isa-ext		: sstc,sscofpmf
> mmu		: sv48
>
> processor	: 3
> hart		: 3
> isa		: rv64imafdcsu
> isa-ext		: sstc,sscofpmf
> mmu		: sv48
>
> Anybody adding support for any new multi-letter extensions should add an
> entry to the riscv_isa_ext_id and the isa extension array.
> E.g. The patch[1] adds the support for sscofpmf extension.
>
> [1] https://github.com/atishp04/linux/commit/a23157264118d6fd905fd08d8717c7df03078bb1
>
> Atish Patra (2):
> RISC-V: Provide a framework for parsing multi-letter ISA extensions
> dt-bindings: riscv: Add DT binding for RISC-V ISA extensions
>
> .../devicetree/bindings/riscv/cpus.yaml       |  9 +++
> arch/riscv/include/asm/hwcap.h                | 31 ++++++++++
> arch/riscv/kernel/cpu.c                       | 16 +++++
> arch/riscv/kernel/cpufeature.c                | 58 ++++++++++++++++++-
> 4 files changed, 113 insertions(+), 1 deletion(-)