From: Conor Dooley <conor.dooley@microchip.com>
To: Evan Green <evan@rivosinc.com>
Cc: Anup Patel <apatel@ventanamicro.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Palmer Dabbelt <palmer@rivosinc.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-riscv@lists.infradead.org,
Heiko Stuebner <heiko.stuebner@vrull.eu>,
Andrew Jones <ajones@ventanamicro.com>
Subject: Re: [PATCH v4] RISC-V: Show accurate per-hart isa in /proc/cpuinfo
Date: Thu, 24 Aug 2023 13:20:06 +0100 [thread overview]
Message-ID: <20230824-factual-jawed-2dddd2cf2bdd@wendy> (raw)
In-Reply-To: <20230711201831.2695097-1-evan@rivosinc.com>
[-- Attachment #1.1: Type: text/plain, Size: 4915 bytes --]
On Tue, Jul 11, 2023 at 01:18:30PM -0700, Evan Green wrote:
> In /proc/cpuinfo, most of the information we show for each processor is
> specific to that hart: marchid, mvendorid, mimpid, processor, hart,
> compatible, and the mmu size. But the ISA string gets filtered through a
> lowest common denominator mask, so that if one CPU is missing an ISA
> extension, no CPUs will show it.
>
> Now that we track the ISA extensions for each hart, let's report ISA
> extension info accurately per-hart in /proc/cpuinfo. We cannot change
> the "isa:" line, as usermode may be relying on that line to show only
> the common set of extensions supported across all harts. Add a new "hart
> isa" line instead, which reports the true set of extensions for that
> hart. This matches what is returned in riscv_hwprobe() when querying a
> given hart.
>
> Signed-off-by: Evan Green <evan@rivosinc.com>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>
> ---
>
> Changes in v4:
> - Documentation: Made the underline match the text line (Conor)
> - Documentation: hanged "in question" to "being described" (Andrew)
>
> Changes in v3:
> - Add some documentation (Conor)
>
> Changes in v2:
> - Added new "hart isa" line rather than altering behavior of existing
> "isa" line (Conor, Palmer)
>
>
> I based this series on top of Conor's riscv-extensions-strings branch
> from July 3rd, since otherwise this change gets hopelessly entangled
> with that series.
>
> ---
> Documentation/riscv/uabi.rst | 10 ++++++++++
> arch/riscv/kernel/cpu.c | 22 ++++++++++++++++++----
> 2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst
> index 8960fac42c40..afdda580e5a2 100644
> --- a/Documentation/riscv/uabi.rst
> +++ b/Documentation/riscv/uabi.rst
> @@ -42,6 +42,16 @@ An example string following the order is::
>
> rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
>
> +"isa" vs "hart isa" lines in /proc/cpuinfo
> +------------------------------------------
> +
> +The "isa" line in /proc/cpuinfo describes the lowest common denominator of
> +RISC-V ISA extensions understood by the kernel and implemented on all harts. The
> +"hart isa" line, in contrast, describes the set of extensions understood by the
> +kernel on the particular hart being described, even if those extensions may not
> +be present on all harts in the system. The "hart isa" line is consistent with
> +what's returned by __riscv_hwprobe() when querying for that specific CPU.
Thinking about this again, I don't think this is true. hwprobe uses
has_fpu(), has_vector() etc that interact with Kconfig options but the
percpu isa bitmap isn't affected by these.
> +
> Misaligned accesses
> -------------------
>
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index 1acf3679600d..6264b7b94945 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -197,9 +197,8 @@ arch_initcall(riscv_cpuinfo_init);
>
> #ifdef CONFIG_PROC_FS
>
> -static void print_isa(struct seq_file *f)
> +static void print_isa(struct seq_file *f, const unsigned long *isa_bitmap)
> {
> - seq_puts(f, "isa\t\t: ");
>
> if (IS_ENABLED(CONFIG_32BIT))
> seq_write(f, "rv32", 4);
> @@ -207,7 +206,7 @@ static void print_isa(struct seq_file *f)
> seq_write(f, "rv64", 4);
>
> for (int i = 0; i < riscv_isa_ext_count; i++) {
> - if (!__riscv_isa_extension_available(NULL, riscv_isa_ext[i].id))
> + if (!__riscv_isa_extension_available(isa_bitmap, riscv_isa_ext[i].id))
> continue;
>
> /* Only multi-letter extensions are split by underscores */
> @@ -271,7 +270,15 @@ static int c_show(struct seq_file *m, void *v)
>
> seq_printf(m, "processor\t: %lu\n", cpu_id);
> seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hartid_map(cpu_id));
> - print_isa(m);
> +
> + /*
> + * For historical raisins, the isa: line is limited to the lowest common
> + * denominator of extensions supported across all harts. A true list of
> + * extensions supported on this hart is printed later in the hart_isa:
> + * line.
> + */
> + seq_puts(m, "isa\t\t: ");
> + print_isa(m, NULL);
> print_mmu(m);
>
> if (acpi_disabled) {
> @@ -287,6 +294,13 @@ static int c_show(struct seq_file *m, void *v)
> seq_printf(m, "mvendorid\t: 0x%lx\n", ci->mvendorid);
> seq_printf(m, "marchid\t\t: 0x%lx\n", ci->marchid);
> seq_printf(m, "mimpid\t\t: 0x%lx\n", ci->mimpid);
> +
> + /*
> + * Print the ISA extensions specific to this hart, which may show
> + * additional extensions not present across all harts.
> + */
> + seq_puts(m, "hart isa\t: ");
> + print_isa(m, hart_isa[cpu_id].isa);
> seq_puts(m, "\n");
>
> return 0;
> --
> 2.34.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-08-24 12:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 20:18 [PATCH v4] RISC-V: Show accurate per-hart isa in /proc/cpuinfo Evan Green
2023-08-24 12:20 ` Conor Dooley [this message]
2023-08-24 16:18 ` Evan Green
2023-08-24 17:29 ` Conor Dooley
2023-08-24 22:06 ` Evan Green
2023-08-24 22:27 ` Conor Dooley
2023-08-24 22:45 ` Evan Green
2023-08-25 8:16 ` Andrew Jones
2023-08-25 22:51 ` Evan Green
2023-08-26 8:01 ` Andrew Jones
2023-08-28 16:44 ` Evan Green
2023-08-28 17:13 ` Conor Dooley
2023-08-29 8:48 ` Andrew Jones
2023-08-29 17:20 ` Evan Green
2023-08-30 9:03 ` Andrew Jones
2023-08-30 17:33 ` Evan Green
2023-08-30 17:55 ` Andrew Jones
2023-08-30 13:24 ` Palmer Dabbelt
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=20230824-factual-jawed-2dddd2cf2bdd@wendy \
--to=conor.dooley@microchip.com \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=bagasdotme@gmail.com \
--cc=corbet@lwn.net \
--cc=evan@rivosinc.com \
--cc=heiko.stuebner@vrull.eu \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=paul.walmsley@sifive.com \
/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