All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evan Green <evan@rivosinc.com>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Conor Dooley <conor@kernel.org>,
	vineetg@rivosinc.com, heiko@sntech.de, slewis@rivosinc.com,
	Evan Green <evan@rivosinc.com>, Albert Ou <aou@eecs.berkeley.edu>,
	Andrew Bresticker <abrestic@rivosinc.com>,
	Andrew Jones <ajones@ventanamicro.com>,
	Anup Patel <apatel@ventanamicro.com>,
	Arnd Bergmann <arnd@arndb.de>, Atish Patra <atishp@rivosinc.com>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Celeste Liu <coelacanthus@outlook.com>,
	Conor Dooley <conor.dooley@microchip.com>,
	Dao Lu <daolu@rivosinc.com>, Guo Ren <guoren@kernel.org>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Jisheng Zhang <jszhang@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Mark Brown <broonie@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Qinglin Pan <panqinglin2020@iscas.ac.cn>,
	Randy Dunlap <rdunlap@infradead.org>,
	Rob Herring <robh+dt@kernel.org>, Ruizhe Pan <c141028@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	Sunil V L <sunilvl@ventanamicro.com>,
	Tobias Klauser <tklauser@distanz.ch>,
	Tsukasa OI <research_trasio@irq.a4lg.com>,
	Xianting Tian <xianting.tian@linux.alibaba.com>,
	devicetree@vger.kernel.org, dram <dramforever@live.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: [PATCH v2 0/6] RISC-V Hardware Probing User Interface
Date: Mon,  6 Feb 2023 12:14:49 -0800	[thread overview]
Message-ID: <20230206201455.1790329-1-evan@rivosinc.com> (raw)


These are very much up for discussion, as it's a pretty big new user
interface and it's quite a bit different from how we've historically
done things: this isn't just providing an ISA string to userspace, this
has its own format for providing information to userspace.

There's been a bunch of off-list discussions about this, including at
Plumbers.  The original plan was to do something involving providing an
ISA string to userspace, but ISA strings just aren't sufficient for a
stable ABI any more: in order to parse an ISA string users need the
version of the specifications that the string is written to, the version
of each extension (sometimes at a finer granularity than the RISC-V
releases/versions encode), and the expected use case for the ISA string
(ie, is it a U-mode or M-mode string).  That's a lot of complexity to
try and keep ABI compatible and it's probably going to continue to grow,
as even if there's no more complexity in the specifications we'll have
to deal with the various ISA string parsing oddities that end up all
over userspace.

Instead this patch set takes a very different approach and provides a set
of key/value pairs that encode various bits about the system.  The big
advantage here is that we can clearly define what these mean so we can
ensure ABI stability, but it also allows us to encode information that's
unlikely to ever appear in an ISA string (see the misaligned access
performance, for example).  The resulting interface looks a lot like
what arm64 and x86 do, and will hopefully fit well into something like
ACPI in the future.

The actual user interface is a syscall.  I'm not really sure that's the
right way to go about this, but it makes for flexible prototying.
Various other approaches have been talked about like making HWCAP2 a
pointer, having a VDSO routine, or exposing this via sysfs.  Those seem
like generally reasonable approaches, but I've yet to figure out a way
to get the general case working without a syscall as that's the only way
I've come up with to deal with the heterogenous CPU case.  Happy to hear
if someone has a better idea, though, as I don't really want to add a
syscall if we can avoid it.

An example series in glibc exposing this syscall and using it in an
ifunc selector for memcpy can be found at [1].

[1] https://public-inbox.org/libc-alpha/20230206194819.1679472-1-evan@rivosinc.com/T/#t

Changes in v2:
 - Changed the interface to look more like poll(). Rather than supplying
   key_offset and getting back an array of values with numerically
   contiguous keys, have the user pre-fill the key members of the array,
   and the kernel will fill in the corresponding values. For any key it
   doesn't recognize, it will set the key of that element to -1. This
   allows usermode to quickly ask for exactly the elements it cares
   about, and not get bogged down in a back and forth about newer keys
   that older kernels might not recognize. In other words, the kernel
   can communicate that it doesn't recognize some of the keys while
   still providing the data for the keys it does know.
 - Added a shortcut to the cpuset parameters that if a size of 0 and
   NULL is provided for the CPU set, the kernel will use a cpu mask of
   all online CPUs. This is convenient because I suspect most callers
   will only want to act on a feature if it's supported on all CPUs, and
   it's a headache to dynamically allocate an array of all 1s, not to
   mention a waste to have the kernel loop over all of the offline bits.
 - Fixed logic error in if(of_property_read_string...) that caused crash
 - Include cpufeature.h in cpufeature.h to avoid undeclared variable
   warning.
 - Added a _MASK define
 - Fix random checkpatch complaints
 - Updated the selftests to the new API and added some more.
 - Fixed indentation, comments in .S, and general checkpatch complaints.

Evan Green (4):
  RISC-V: Move struct riscv_cpuinfo to new header
  RISC-V: Add a syscall for HW probing
  RISC-V: hwprobe: Support probing of misaligned access performance
  selftests: Test the new RISC-V hwprobe interface

Palmer Dabbelt (2):
  RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA
  dt-bindings: Add RISC-V misaligned access performance

 .../devicetree/bindings/riscv/cpus.yaml       |  15 ++
 Documentation/riscv/hwprobe.rst               |  66 ++++++
 Documentation/riscv/index.rst                 |   1 +
 arch/riscv/include/asm/cpufeature.h           |  23 +++
 arch/riscv/include/asm/hwprobe.h              |  13 ++
 arch/riscv/include/asm/smp.h                  |   9 +
 arch/riscv/include/asm/syscall.h              |   3 +
 arch/riscv/include/uapi/asm/hwprobe.h         |  35 ++++
 arch/riscv/include/uapi/asm/unistd.h          |   8 +
 arch/riscv/kernel/cpu.c                       |  11 +-
 arch/riscv/kernel/cpufeature.c                |  31 ++-
 arch/riscv/kernel/sys_riscv.c                 | 192 +++++++++++++++++-
 tools/testing/selftests/Makefile              |   1 +
 tools/testing/selftests/riscv/Makefile        |  58 ++++++
 .../testing/selftests/riscv/hwprobe/Makefile  |  10 +
 .../testing/selftests/riscv/hwprobe/hwprobe.c |  89 ++++++++
 .../selftests/riscv/hwprobe/sys_hwprobe.S     |  12 ++
 tools/testing/selftests/riscv/libc.S          |  46 +++++
 18 files changed, 613 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/riscv/hwprobe.rst
 create mode 100644 arch/riscv/include/asm/cpufeature.h
 create mode 100644 arch/riscv/include/asm/hwprobe.h
 create mode 100644 arch/riscv/include/uapi/asm/hwprobe.h
 create mode 100644 tools/testing/selftests/riscv/Makefile
 create mode 100644 tools/testing/selftests/riscv/hwprobe/Makefile
 create mode 100644 tools/testing/selftests/riscv/hwprobe/hwprobe.c
 create mode 100644 tools/testing/selftests/riscv/hwprobe/sys_hwprobe.S
 create mode 100644 tools/testing/selftests/riscv/libc.S

-- 
2.25.1


WARNING: multiple messages have this Message-ID (diff)
From: Evan Green <evan@rivosinc.com>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: heiko@sntech.de, Jisheng Zhang <jszhang@kernel.org>,
	linux-doc@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Bresticker <abrestic@rivosinc.com>,
	Atish Patra <atishp@rivosinc.com>,
	Rob Herring <robh+dt@kernel.org>,
	Conor Dooley <conor.dooley@microchip.com>,
	Celeste Liu <coelacanthus@outlook.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Qinglin Pan <panqinglin2020@iscas.ac.cn>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-riscv@lists.infradead.org, Jonathan Corbet <corbet@lwn.net>,
	Xianting Tian <xianting.tian@linux.alibaba.com>,
	Tsukasa OI <research_trasio@irq.a4lg.com>,
	Tobias Klauser <tklauser@distanz.ch>,
	Andrew Jones <ajones@ventanamicro.com>,
	devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
	Arnd Bergmann <arnd@arndb.de>,
	vineetg@rivosinc.com, Mark Brown <broonie@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Ruizhe Pan <c141028@gmail.com>,
	Anup Patel <apatel@ventanamicro.com>,
	linux-kselftest@vger.kernel.org, slewis@rivosinc.com,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-kernel@vger.kernel.org, Conor Dooley <conor@kernel.org>,
	dram <dramforever@live.com>, Evan Green <evan@rivosinc.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Guo Ren <guoren@kernel.org>, Dao Lu <daolu@rivosinc.com>
Subject: [PATCH v2 0/6] RISC-V Hardware Probing User Interface
Date: Mon,  6 Feb 2023 12:14:49 -0800	[thread overview]
Message-ID: <20230206201455.1790329-1-evan@rivosinc.com> (raw)


These are very much up for discussion, as it's a pretty big new user
interface and it's quite a bit different from how we've historically
done things: this isn't just providing an ISA string to userspace, this
has its own format for providing information to userspace.

There's been a bunch of off-list discussions about this, including at
Plumbers.  The original plan was to do something involving providing an
ISA string to userspace, but ISA strings just aren't sufficient for a
stable ABI any more: in order to parse an ISA string users need the
version of the specifications that the string is written to, the version
of each extension (sometimes at a finer granularity than the RISC-V
releases/versions encode), and the expected use case for the ISA string
(ie, is it a U-mode or M-mode string).  That's a lot of complexity to
try and keep ABI compatible and it's probably going to continue to grow,
as even if there's no more complexity in the specifications we'll have
to deal with the various ISA string parsing oddities that end up all
over userspace.

Instead this patch set takes a very different approach and provides a set
of key/value pairs that encode various bits about the system.  The big
advantage here is that we can clearly define what these mean so we can
ensure ABI stability, but it also allows us to encode information that's
unlikely to ever appear in an ISA string (see the misaligned access
performance, for example).  The resulting interface looks a lot like
what arm64 and x86 do, and will hopefully fit well into something like
ACPI in the future.

The actual user interface is a syscall.  I'm not really sure that's the
right way to go about this, but it makes for flexible prototying.
Various other approaches have been talked about like making HWCAP2 a
pointer, having a VDSO routine, or exposing this via sysfs.  Those seem
like generally reasonable approaches, but I've yet to figure out a way
to get the general case working without a syscall as that's the only way
I've come up with to deal with the heterogenous CPU case.  Happy to hear
if someone has a better idea, though, as I don't really want to add a
syscall if we can avoid it.

An example series in glibc exposing this syscall and using it in an
ifunc selector for memcpy can be found at [1].

[1] https://public-inbox.org/libc-alpha/20230206194819.1679472-1-evan@rivosinc.com/T/#t

Changes in v2:
 - Changed the interface to look more like poll(). Rather than supplying
   key_offset and getting back an array of values with numerically
   contiguous keys, have the user pre-fill the key members of the array,
   and the kernel will fill in the corresponding values. For any key it
   doesn't recognize, it will set the key of that element to -1. This
   allows usermode to quickly ask for exactly the elements it cares
   about, and not get bogged down in a back and forth about newer keys
   that older kernels might not recognize. In other words, the kernel
   can communicate that it doesn't recognize some of the keys while
   still providing the data for the keys it does know.
 - Added a shortcut to the cpuset parameters that if a size of 0 and
   NULL is provided for the CPU set, the kernel will use a cpu mask of
   all online CPUs. This is convenient because I suspect most callers
   will only want to act on a feature if it's supported on all CPUs, and
   it's a headache to dynamically allocate an array of all 1s, not to
   mention a waste to have the kernel loop over all of the offline bits.
 - Fixed logic error in if(of_property_read_string...) that caused crash
 - Include cpufeature.h in cpufeature.h to avoid undeclared variable
   warning.
 - Added a _MASK define
 - Fix random checkpatch complaints
 - Updated the selftests to the new API and added some more.
 - Fixed indentation, comments in .S, and general checkpatch complaints.

Evan Green (4):
  RISC-V: Move struct riscv_cpuinfo to new header
  RISC-V: Add a syscall for HW probing
  RISC-V: hwprobe: Support probing of misaligned access performance
  selftests: Test the new RISC-V hwprobe interface

Palmer Dabbelt (2):
  RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA
  dt-bindings: Add RISC-V misaligned access performance

 .../devicetree/bindings/riscv/cpus.yaml       |  15 ++
 Documentation/riscv/hwprobe.rst               |  66 ++++++
 Documentation/riscv/index.rst                 |   1 +
 arch/riscv/include/asm/cpufeature.h           |  23 +++
 arch/riscv/include/asm/hwprobe.h              |  13 ++
 arch/riscv/include/asm/smp.h                  |   9 +
 arch/riscv/include/asm/syscall.h              |   3 +
 arch/riscv/include/uapi/asm/hwprobe.h         |  35 ++++
 arch/riscv/include/uapi/asm/unistd.h          |   8 +
 arch/riscv/kernel/cpu.c                       |  11 +-
 arch/riscv/kernel/cpufeature.c                |  31 ++-
 arch/riscv/kernel/sys_riscv.c                 | 192 +++++++++++++++++-
 tools/testing/selftests/Makefile              |   1 +
 tools/testing/selftests/riscv/Makefile        |  58 ++++++
 .../testing/selftests/riscv/hwprobe/Makefile  |  10 +
 .../testing/selftests/riscv/hwprobe/hwprobe.c |  89 ++++++++
 .../selftests/riscv/hwprobe/sys_hwprobe.S     |  12 ++
 tools/testing/selftests/riscv/libc.S          |  46 +++++
 18 files changed, 613 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/riscv/hwprobe.rst
 create mode 100644 arch/riscv/include/asm/cpufeature.h
 create mode 100644 arch/riscv/include/asm/hwprobe.h
 create mode 100644 arch/riscv/include/uapi/asm/hwprobe.h
 create mode 100644 tools/testing/selftests/riscv/Makefile
 create mode 100644 tools/testing/selftests/riscv/hwprobe/Makefile
 create mode 100644 tools/testing/selftests/riscv/hwprobe/hwprobe.c
 create mode 100644 tools/testing/selftests/riscv/hwprobe/sys_hwprobe.S
 create mode 100644 tools/testing/selftests/riscv/libc.S

-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

             reply	other threads:[~2023-02-06 20:15 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06 20:14 Evan Green [this message]
2023-02-06 20:14 ` [PATCH v2 0/6] RISC-V Hardware Probing User Interface Evan Green
2023-02-06 20:14 ` [PATCH v2 1/6] RISC-V: Move struct riscv_cpuinfo to new header Evan Green
2023-02-06 20:14   ` Evan Green
2023-02-14 21:38   ` Conor Dooley
2023-02-14 21:38     ` Conor Dooley
2023-02-14 21:57     ` Evan Green
2023-02-14 21:57       ` Evan Green
2023-02-06 20:14 ` [PATCH v2 2/6] RISC-V: Add a syscall for HW probing Evan Green
2023-02-06 20:14   ` Evan Green
2023-02-07  6:13   ` Greg KH
2023-02-07  6:13     ` Greg KH
2023-02-07  6:32     ` Conor Dooley
2023-02-07  6:32       ` Conor Dooley
2023-02-09 17:09       ` Evan Green
2023-02-09 17:09         ` Evan Green
2023-02-09 17:13         ` Greg KH
2023-02-09 17:13           ` Greg KH
2023-02-09 17:22           ` Jessica Clarke
2023-02-09 17:22             ` Jessica Clarke
2023-02-10  6:48             ` Greg KH
2023-02-10  6:48               ` Greg KH
2023-02-09 18:41           ` Evan Green
2023-02-09 18:41             ` Evan Green
2023-02-10  6:50             ` Greg KH
2023-02-10  6:50               ` Greg KH
2023-02-07 23:16   ` kernel test robot
2023-02-07 23:16     ` kernel test robot
2023-02-14 23:51   ` Conor Dooley
2023-02-14 23:51     ` Conor Dooley
2023-02-15  8:04     ` Andrew Jones
2023-02-15  8:04       ` Andrew Jones
2023-02-15 20:49     ` Evan Green
2023-02-15 20:49       ` Evan Green
2023-02-15 21:10       ` Conor Dooley
2023-02-15 21:10         ` Conor Dooley
2023-02-15  9:56   ` Arnd Bergmann
2023-02-15  9:56     ` Arnd Bergmann
2023-02-15 21:14     ` Evan Green
2023-02-15 21:14       ` Evan Green
2023-02-15 22:43       ` Jessica Clarke
2023-02-15 22:43         ` Jessica Clarke
2023-02-16 13:28         ` Arnd Bergmann
2023-02-16 13:28           ` Arnd Bergmann
2023-02-16 23:18           ` Evan Green
2023-02-16 23:18             ` Evan Green
2023-02-06 20:14 ` [PATCH v2 3/6] RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA Evan Green
2023-02-06 20:14   ` Evan Green
2023-02-08  5:06   ` kernel test robot
2023-02-15 21:25   ` Conor Dooley
2023-02-15 21:25     ` Conor Dooley
2023-02-15 22:09   ` Conor Dooley
2023-02-15 22:09     ` Conor Dooley
2023-02-06 20:14 ` [PATCH v2 4/6] dt-bindings: Add RISC-V misaligned access performance Evan Green
2023-02-06 20:14   ` Evan Green
2023-02-06 21:49   ` Rob Herring
2023-02-06 21:49     ` Rob Herring
2023-02-07 17:05   ` Rob Herring
2023-02-07 17:05     ` Rob Herring
2023-02-08 12:45     ` David Laight
2023-02-08 12:45       ` David Laight
2023-02-09 16:51       ` Palmer Dabbelt
2023-02-09 16:51         ` Palmer Dabbelt
2023-02-28 14:56         ` Rob Herring
2023-02-28 14:56           ` Rob Herring
2023-02-14 21:26   ` Conor Dooley
2023-02-14 21:26     ` Conor Dooley
2023-02-15 20:50     ` Evan Green
2023-02-15 20:50       ` Evan Green
2023-02-06 20:14 ` [PATCH v2 5/6] RISC-V: hwprobe: Support probing of " Evan Green
2023-02-06 20:14   ` Evan Green
2023-02-07  7:02   ` kernel test robot
2023-02-07  7:02     ` kernel test robot
2023-02-15 21:57   ` Conor Dooley
2023-02-15 21:57     ` Conor Dooley
2023-02-18  0:15     ` Evan Green
2023-02-18  0:15       ` Evan Green
2023-02-06 20:14 ` [PATCH v2 6/6] selftests: Test the new RISC-V hwprobe interface Evan Green
2023-02-06 20:14   ` Evan Green
2023-02-06 21:27   ` Mark Brown
2023-02-06 21:27     ` Mark Brown
2023-02-09 18:44     ` Evan Green
2023-02-09 18:44       ` Evan Green
2023-02-06 21:11 ` [PATCH v2 0/6] RISC-V Hardware Probing User Interface Jessica Clarke
2023-02-06 21:11   ` Jessica Clarke
2023-02-06 22:47   ` Heinrich Schuchardt
2023-02-06 22:47     ` Heinrich Schuchardt
2023-02-09 16:56     ` Palmer Dabbelt
2023-02-09 16:56       ` Palmer Dabbelt
2023-02-06 22:32 ` Conor Dooley
2023-02-06 22:32   ` Conor Dooley

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=20230206201455.1790329-1-evan@rivosinc.com \
    --to=evan@rivosinc.com \
    --cc=abrestic@rivosinc.com \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=arnd@arndb.de \
    --cc=atishp@rivosinc.com \
    --cc=bagasdotme@gmail.com \
    --cc=broonie@kernel.org \
    --cc=c141028@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=coelacanthus@outlook.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daolu@rivosinc.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dramforever@live.com \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=jszhang@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=palmer@rivosinc.com \
    --cc=panqinglin2020@iscas.ac.cn \
    --cc=paul.walmsley@sifive.com \
    --cc=rdunlap@infradead.org \
    --cc=research_trasio@irq.a4lg.com \
    --cc=robh+dt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=slewis@rivosinc.com \
    --cc=sunilvl@ventanamicro.com \
    --cc=tklauser@distanz.ch \
    --cc=vineetg@rivosinc.com \
    --cc=xianting.tian@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.