mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-14 22:44:27 +08:00
16252e018a
Evan Green <evan@rivosinc.com> says: This change detects the presence of Zba, Zbb, and Zbs extensions and exports them per-hart to userspace via the hwprobe mechanism. Glibc can then use these in setting up hwcaps-based library search paths. There's a little bit of extra housekeeping here: the first change adds Zba and Zbs to the set of extensions the kernel recognizes, and the second change starts tracking ISA features per-hart (in addition to the ANDed mask of features across all harts which the kernel uses to make decisions). Now that we track the ISA information per-hart, we could even fix up /proc/cpuinfo to accurately report extension per-hart, though I've left that out of this series for now. * b4-shazam-merge: RISC-V: hwprobe: Expose Zba, Zbb, and Zbs RISC-V: Track ISA extensions per hart RISC-V: Add Zba, Zbs extension probing Link: https://lore.kernel.org/r/20230509182504.2997252-1-evan@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
100 lines
4.4 KiB
ReStructuredText
100 lines
4.4 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
RISC-V Hardware Probing Interface
|
|
---------------------------------
|
|
|
|
The RISC-V hardware probing interface is based around a single syscall, which
|
|
is defined in <asm/hwprobe.h>::
|
|
|
|
struct riscv_hwprobe {
|
|
__s64 key;
|
|
__u64 value;
|
|
};
|
|
|
|
long sys_riscv_hwprobe(struct riscv_hwprobe *pairs, size_t pair_count,
|
|
size_t cpu_count, cpu_set_t *cpus,
|
|
unsigned int flags);
|
|
|
|
The arguments are split into three groups: an array of key-value pairs, a CPU
|
|
set, and some flags. The key-value pairs are supplied with a count. Userspace
|
|
must prepopulate the key field for each element, and the kernel will fill in the
|
|
value if the key is recognized. If a key is unknown to the kernel, its key field
|
|
will be cleared to -1, and its value set to 0. The CPU set is defined by
|
|
CPU_SET(3). For value-like keys (eg. vendor/arch/impl), the returned value will
|
|
be only be valid if all CPUs in the given set have the same value. Otherwise -1
|
|
will be returned. For boolean-like keys, the value returned will be a logical
|
|
AND of the values for the specified CPUs. Usermode can supply NULL for cpus and
|
|
0 for cpu_count as a shortcut for all online CPUs. There are currently no flags,
|
|
this value must be zero for future compatibility.
|
|
|
|
On success 0 is returned, on failure a negative error code is returned.
|
|
|
|
The following keys are defined:
|
|
|
|
* :c:macro:`RISCV_HWPROBE_KEY_MVENDORID`: Contains the value of ``mvendorid``,
|
|
as defined by the RISC-V privileged architecture specification.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_KEY_MARCHID`: Contains the value of ``marchid``, as
|
|
defined by the RISC-V privileged architecture specification.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_KEY_MIMPLID`: Contains the value of ``mimplid``, as
|
|
defined by the RISC-V privileged architecture specification.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_KEY_BASE_BEHAVIOR`: A bitmask containing the base
|
|
user-visible behavior that this kernel supports. The following base user ABIs
|
|
are defined:
|
|
|
|
* :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: Support for rv32ima or
|
|
rv64ima, as defined by version 2.2 of the user ISA and version 1.10 of the
|
|
privileged ISA, with the following known exceptions (more exceptions may be
|
|
added, but only if it can be demonstrated that the user ABI is not broken):
|
|
|
|
* The :fence.i: instruction cannot be directly executed by userspace
|
|
programs (it may still be executed in userspace via a
|
|
kernel-controlled mechanism such as the vDSO).
|
|
|
|
* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0`: A bitmask containing the extensions
|
|
that are compatible with the :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`:
|
|
base system behavior.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_IMA_FD`: The F and D extensions are supported, as
|
|
defined by commit cd20cee ("FMIN/FMAX now implement
|
|
minimumNumber/maximumNumber, not minNum/maxNum") of the RISC-V ISA manual.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_IMA_C`: The C extension is supported, as defined
|
|
by version 2.2 of the RISC-V ISA manual.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_IMA_V`: The V extension is supported, as defined by
|
|
version 1.0 of the RISC-V Vector extension manual.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is
|
|
supported, as defined in version 1.0 of the Bit-Manipulation ISA
|
|
extensions.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined
|
|
in version 1.0 of the Bit-Manipulation ISA extensions.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
|
|
in version 1.0 of the Bit-Manipulation ISA extensions.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
|
|
information about the selected set of processors.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNKNOWN`: The performance of misaligned
|
|
accesses is unknown.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_MISALIGNED_EMULATED`: Misaligned accesses are
|
|
emulated via software, either in or below the kernel. These accesses are
|
|
always extremely slow.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported
|
|
in hardware, but are slower than the cooresponding aligned accesses
|
|
sequences.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported
|
|
in hardware and are faster than the cooresponding aligned accesses
|
|
sequences.
|
|
|
|
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
|
|
not supported at all and will generate a misaligned address fault.
|