From: Jisheng Zhang <jszhang@kernel.org>
To: Atish Patra <atishp@rivosinc.com>
Cc: linux-kernel@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Atish Patra <atishp@atishpatra.org>,
Anup Patel <anup@brainfault.org>,
Damien Le Moal <damien.lemoal@wdc.com>,
devicetree@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
linux-riscv@lists.infradead.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v3 0/6] Provide a fraemework for RISC-V ISA extensions
Date: Tue, 15 Feb 2022 23:56:57 +0800 [thread overview]
Message-ID: <YgvNSeUekqEVS1yE@xhacker> (raw)
In-Reply-To: <20220215090211.911366-1-atishp@rivosinc.com>
On Tue, Feb 15, 2022 at 01:02:05AM -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 : rv64imafdcsu
> isa-ext : sstc,sscofpmf
> mmu : sv48
>
> 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[2] adds the support for various ISA extensions.
Hi Atish,
Thanks for this series. I'm thinking cpu features VS ISA extenstions.
I'm converting the sv48 to static key:
https://lore.kernel.org/linux-riscv/20220125165036.987-1-jszhang@kernel.org/
Previously, I thought the SV48 as a cpu feature, and there will be
more and more cpu features, so I implemented an unified static key
mechanism for CPU features. But after reading this series, I think
I may need to rebase(even reimplement) the above patch to your series.
But I'm a bit confused by CPU features VS ISA extenstions now:
1. Is cpu feature == ISA extension?
2. Is SV48 considered as ISA extension?
If yes, now SV48 or not is determined during runtime, but current ISA
extensions seem parsed from DT. So how to support those ISA extensions
which can be determined during runtime?
Could you please share your thought?
Thanks
next prev parent reply other threads:[~2022-02-15 16:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-15 9:02 [PATCH v3 0/6] Provide a fraemework for RISC-V ISA extensions Atish Patra
2022-02-15 9:02 ` [PATCH v3 1/6] RISC-V: Correctly print supported extensions Atish Patra
2022-02-15 9:41 ` Anup Patel
2022-02-15 9:02 ` [PATCH v3 2/6] RISC-V: Minimal parser for "riscv, isa" strings Atish Patra
2022-02-15 9:02 ` [PATCH v3 3/6] RISC-V: Extract multi-letter extension names from "riscv, isa" Atish Patra
2022-02-15 10:14 ` Anup Patel
2022-02-15 9:02 ` [PATCH v3 4/6] RISC-V: Implement multi-letter ISA extension probing framework Atish Patra
2022-02-15 10:23 ` Anup Patel
2022-02-15 23:11 ` Atish Patra
2022-02-15 9:02 ` [PATCH v3 5/6] RISC-V: Do no continue isa string parsing without correct XLEN Atish Patra
2022-02-15 9:02 ` [PATCH v3 6/6] RISC-V: Improve /proc/cpuinfo output for ISA extensions Atish Patra
2022-02-15 15:56 ` Jisheng Zhang [this message]
2022-02-15 19:06 ` [PATCH v3 0/6] Provide a fraemework for RISC-V " Atish Kumar Patra
2022-03-26 7:18 ` Jisheng Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YgvNSeUekqEVS1yE@xhacker \
--to=jszhang@kernel.org \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@atishpatra.org \
--cc=atishp@rivosinc.com \
--cc=damien.lemoal@wdc.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).