| Message ID | 20211224211632.1698523-1-atishp@rivosinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Provide a fraemework for RISC-V ISA extensions | expand |
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