| Message ID | 20211224211632.1698523-1-atishp@rivosinc.com |
|---|---|
| Headers | show |
| Series | Provide a fraemework for RISC-V ISA extensions | expand |
On 24/12/2021 22:16, Atish Patra wrote: > Recently, there were 15 specifications/40 ISA extensions were ratified. > Except hypervisor ('H') extension, all of them are multi-letter extensions. > Going forward, there will be more number of multi-letter extensions as > well. Parsing all of these extensions from ISA string is not scalable. > Thus, this patch provides a DT based framework to for easy parsing and > querying of any ISA extensions. It facilitates custom user visible strings > for the ISA extensions via /proc/cpuinfo as well. > > Currently, there are no platforms with heterogeneous Linux capable harts. > That's why, this patch supports only a single DT node which can only work > for systems with homogeneous harts. To support heterogeneous systems, this > cpu node must be a subnode for each cpu. > > Signed-off-by: Atish Patra <atishp@rivosinc.com> Your from address does not match SoB. Please use consistent one - they must match. Best regards, Krzysztof
On Fri, 24 Dec 2021 13:16:30 PST (-0800), atishp@atishpatra.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(-)
On Fri, Jan 7, 2022 at 1:58 PM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Fri, 24 Dec 2021 13:16:30 PST (-0800), atishp@atishpatra.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. > > 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(-) -- Regards, Atish
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@dabbelt.com> wrote: > > > > On Fri, 24 Dec 2021 13:16:30 PST (-0800), atishp@atishpatra.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