[PATCH v1 0/5] RISC-V Hardware Probing User Interface

[PATCH v1 0/5] RISC-V Hardware Probing User Interface

[Palmer Dabbelt]

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 se
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.

I threw this together during the conferences so I would be surprised if
it's not broken, but I figured it'd be best to just get something on the
lists sooner rather that later.  Happy to have someone go fix my code,
but the new uABI is really going to be the tricky bit here.  There's
some test code included, but I haven't even booted a kernel with these
patches so YMMV.

These are also up at kernel.org/palmer/linux/riscv-hwprobe-v1 in case
that's easier for folks.



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

[PATCH v1 1/5] RISC-V: Add a syscall for HW probing

[Palmer Dabbelt]

We don't have enough space for these all in ELF_HWCAP{,2} and there's no
system call that quite does this, so let's just provide an arch-specific
one to probe for hardware capabilities.  This currently just provides
m{arch,imp,vendor}id, but with the key-value pairs we can pass more in
the future.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
I havn't run this yet.
---
 Documentation/riscv/hwprobe.rst       |  33 +++++++
 Documentation/riscv/index.rst         |   1 +
 arch/riscv/include/asm/cpufeature.h   |  21 +++++
 arch/riscv/include/asm/hwprobe.h      |  13 +++
 arch/riscv/include/asm/syscall.h      |   3 +
 arch/riscv/include/uapi/asm/hwprobe.h |  24 ++++++
 arch/riscv/include/uapi/asm/unistd.h  |   8 ++
 arch/riscv/kernel/cpu.c               |  45 +++++++++-
 arch/riscv/kernel/sys_riscv.c         | 118 +++++++++++++++++++++++++-
 9 files changed, 264 insertions(+), 2 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

diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
new file mode 100644
index 000000000000..be9ebe4af3dc
--- /dev/null
+++ b/Documentation/riscv/hwprobe.rst
@@ -0,0 +1,33 @@
+.. 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 {
+        __u64 key, value;
+    };
+
+    long sys_riscv_hwprobe(struct riscv_hwprobe *pairs, size_t pair_count,
+                           size_t base_key, size_t cpu_count, cpu_set_t *cpus,
+                           unsigned long 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 and an
+base, which is the first key that will be probed for.  The CPU set is defined
+by CPU_SET(3), the indicated features will be supported on all CPUs in the set.
+There are currently no flags, this value must be zero for future compatibility.
+
+On success the number of filled out pairs is returned, on failure a negative
+error code is returned.
+
+The following keys are defined:
+
+* :RISCV_HWPROBE_KEY_MVENDORID:: Contains the value of :mvendorid:, as per the
+  ISA specifications.
+* :RISCV_HWPROBE_KEY_MARCHID:: Contains the value of :marchid:, as per the ISA
+  specifications.
+* :RISCV_HWPROBE_KEY_MIMPLID:: Contains the value of :mimplid:, as per the ISA
+  specifications.
diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
index e23b876ad6eb..1c89bca55aec 100644
--- a/Documentation/riscv/index.rst
+++ b/Documentation/riscv/index.rst
@@ -7,6 +7,7 @@ RISC-V architecture
 
     boot-image-header
     vm-layout
+    hwprobe
     patch-acceptance
 
     features
diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
new file mode 100644
index 000000000000..cbda062de9bd
--- /dev/null
+++ b/arch/riscv/include/asm/cpufeature.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright 2022 Rivos, Inc
+ */
+
+#ifndef _ASM_CPUFEATURE_H
+#define _ASM_CPUFEATURE_H
+
+/*
+ * These are probed via a device_initcall(), via either the SBI or directly
+ * from the cooresponding CSRs.
+ */
+struct riscv_cpuinfo {
+        unsigned long mvendorid;
+        unsigned long marchid;
+        unsigned long mimpid;
+};
+
+DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
+
+#endif
diff --git a/arch/riscv/include/asm/hwprobe.h b/arch/riscv/include/asm/hwprobe.h
new file mode 100644
index 000000000000..08d1c3bdd78a
--- /dev/null
+++ b/arch/riscv/include/asm/hwprobe.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright 2022 Rivos, Inc
+ */
+
+#ifndef _ASM_HWPROBE_H
+#define _ASM_HWPROBE_H
+
+#include <uapi/asm/hwprobe.h>
+
+#define RISCV_HWPROBE_MAX_KEY 2
+
+#endif
diff --git a/arch/riscv/include/asm/syscall.h b/arch/riscv/include/asm/syscall.h
index 384a63b86420..78a6302ef711 100644
--- a/arch/riscv/include/asm/syscall.h
+++ b/arch/riscv/include/asm/syscall.h
@@ -75,4 +75,7 @@ static inline int syscall_get_arch(struct task_struct *task)
 }
 
 asmlinkage long sys_riscv_flush_icache(uintptr_t, uintptr_t, uintptr_t);
+
+asmlinkage long sys_riscv_hwprobe(uintptr_t, uintptr_t, uintptr_t, uintptr_t,
+				  uintptr_t, uintptr_t);
 #endif	/* _ASM_RISCV_SYSCALL_H */
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
new file mode 100644
index 000000000000..88ef9e153637
--- /dev/null
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright 2022 Rivos, Inc
+ */
+
+#ifndef _UAPI_ASM_HWPROBE_H
+#define _UAPI_ASM_HWPROBE_H
+
+#include <linux/types.h>
+
+/*
+ * Interface for probing hardware capabilities from userspace, see
+ * Documentation/riscv/hwprobe.rst for more information.
+ */
+struct riscv_hwprobe {
+    __u64 key, val;
+};
+
+#define RISCV_HWPROBE_KEY_MVENDORID	0
+#define RISCV_HWPROBE_KEY_MARCHID	1
+#define RISCV_HWPROBE_KEY_MIMPID	2
+/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
+
+#endif
diff --git a/arch/riscv/include/uapi/asm/unistd.h b/arch/riscv/include/uapi/asm/unistd.h
index 73d7cdd2ec49..37d47302322a 100644
--- a/arch/riscv/include/uapi/asm/unistd.h
+++ b/arch/riscv/include/uapi/asm/unistd.h
@@ -43,3 +43,11 @@
 #define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15)
 #endif
 __SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache)
+
+/*
+ * Allows userspace to probe
+ */
+#ifndef __NR_riscv_hwprobe
+#define __NR_riscv_hwprobe (__NR_arch_specific_syscall + 14)
+#endif
+__SYSCALL(__NR_riscv_hwprobe, sys_riscv_hwprobe)
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 0be8a2403212..708ddcb6c0e7 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -3,12 +3,16 @@
  * Copyright (C) 2012 Regents of the University of California
  */
 
+#include <linux/cpuhotplug.h>
 #include <linux/init.h>
 #include <linux/seq_file.h>
 #include <linux/of.h>
+#include <asm/cpufeature.h>
+#include <asm/csr.h>
 #include <asm/hwcap.h>
-#include <asm/smp.h>
 #include <asm/pgtable.h>
+#include <asm/sbi.h>
+#include <asm/smp.h>
 
 /*
  * Returns the hart ID of the given device tree node, or -ENODEV if the node
@@ -67,7 +71,46 @@ int riscv_of_parent_hartid(struct device_node *node, unsigned long *hartid)
 	return -1;
 }
 
+DEFINE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
+
+static int riscv_cpuinfo_starting(unsigned int cpu)
+{
+	struct riscv_cpuinfo *ci = this_cpu_ptr(&riscv_cpuinfo);
+
+#if IS_ENABLED(CONFIG_RISCV_SBI)
+	ci->mvendorid = sbi_spec_is_0_1() ? 0 : sbi_get_mvendorid();
+	ci->marchid = sbi_spec_is_0_1() ? 0 : sbi_get_marchid();
+	ci->mimpid = sbi_spec_is_0_1() ? 0 : sbi_get_mimpid();
+#elif IS_ENABLED(CONFIG_RISCV_M_MODE)
+	ci->mvendorid = csr_read(CSR_MVENDORID);
+	ci->marchid = csr_read(CSR_MARCHID);
+	ci->mimpid = csr_read(CSR_MIMPID);
+#else
+	ci->mvendorid = 0;
+	ci->marchid = 0;
+	ci->mimpid = 0;
+#endif
+
+	return 0;
+}
+
+static int __init riscv_cpuinfo_init(void)
+{
+	int ret;
+
+	ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "riscv/cpuinfo:starting",
+				riscv_cpuinfo_starting, NULL);
+	if (ret < 0) {
+		pr_err("cpuinfo: failed to register hotplug callbacks.\n");
+		return ret;
+	}
+
+	return 0;
+}
+device_initcall(riscv_cpuinfo_init);
+
 #ifdef CONFIG_PROC_FS
+
 #define __RISCV_ISA_EXT_DATA(UPROP, EXTID) \
 	{							\
 		.uprop = #UPROP,				\
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 571556bb9261..2b6cb82c3491 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -6,8 +6,11 @@
  */
 
 #include <linux/syscalls.h>
-#include <asm/unistd.h>
 #include <asm/cacheflush.h>
+#include <asm/cpufeature.h>
+#include <asm/hwprobe.h>
+#include <asm/uaccess.h>
+#include <asm/unistd.h>
 #include <asm-generic/mman-common.h>
 
 static long riscv_sys_mmap(unsigned long addr, unsigned long len,
@@ -72,3 +75,116 @@ SYSCALL_DEFINE3(riscv_flush_icache, uintptr_t, start, uintptr_t, end,
 
 	return 0;
 }
+
+static long set_hwprobe(struct riscv_hwprobe __user *pair, u64 key, u64 val)
+{
+	long ret;
+
+	ret = put_user(key, &pair->key);
+	if (ret < 0)
+		return ret;
+	ret = put_user(val, &pair->val);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static long hwprobe_mid(struct riscv_hwprobe __user *pair, size_t key,
+			cpumask_t *cpus)
+{
+	long cpu, id;
+	bool first, valid;
+
+	first = true;
+	valid = false;
+	for_each_cpu(cpu, cpus) {
+		struct riscv_cpuinfo * ci = per_cpu_ptr(&riscv_cpuinfo, cpu);
+		long cpu_id;
+
+		switch (key) {
+		case RISCV_HWPROBE_KEY_MVENDORID:
+			cpu_id = ci->mvendorid;
+			break;
+		case RISCV_HWPROBE_KEY_MIMPID:
+			cpu_id = ci->mimpid;
+			break;
+		case RISCV_HWPROBE_KEY_MARCHID:
+			cpu_id = ci->marchid;
+			break;
+		}
+
+		if (first) {
+			id = cpu_id;
+			valid = true;
+		}
+
+		if (id != cpu_id)
+			valid = false;
+	}
+
+	/*
+	 * put_user() returns 0 on success, so use 1 to indicate it wasn't
+	 * called and we should skip having incremented the output.
+	 */
+	if (!valid)
+		return 1;
+
+	return set_hwprobe(pair, key, id);
+}
+
+static
+long do_riscv_hwprobe(struct riscv_hwprobe __user *pairs, long pair_count,
+		      long key_offset, long cpu_count,
+		      unsigned long __user *cpus_user, unsigned long flags)
+{
+	size_t out, k;
+	long ret;
+	struct cpumask cpus;
+
+	/* Check the reserved flags. */
+	if (flags != 0)
+		return -EINVAL;
+
+	/*
+	 * The only supported values must be the same on all CPUs, but check to
+	 * make sure userspace at least tried to provide something here for
+	 * future compatibility.
+	 */
+	cpumask_clear(&cpus);
+	if (cpu_count > cpumask_size())
+		cpu_count = cpumask_size();
+	ret = copy_from_user(&cpus, cpus_user, cpu_count);
+	if (!ret)
+		return -EFAULT;
+
+	out = 0;
+	k = key_offset;
+	while (out < pair_count && k < RISCV_HWPROBE_MAX_KEY) {
+		long ret;
+
+		switch (k) {
+		case RISCV_HWPROBE_KEY_MVENDORID:
+		case RISCV_HWPROBE_KEY_MARCHID:
+		case RISCV_HWPROBE_KEY_MIMPID:
+			ret = hwprobe_mid(pairs + out, k, &cpus);
+			break;
+		}
+
+		if (ret < 0)
+			return ret;
+		if (ret == 0)
+			out++;
+	}
+
+	return out;
+
+}
+
+SYSCALL_DEFINE6(riscv_hwprobe, uintptr_t, pairs, uintptr_t, pair_count,
+		uintptr_t, offset, uintptr_t, cpu_count, uintptr_t, cpus,
+		uintptr_t, flags)
+{
+	return do_riscv_hwprobe((void __user *)pairs, pair_count, offset,
+				cpu_count, (void __user *)cpus, flags);
+}
-- 
2.38.0


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

[PATCH v1 2/5] RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA

[Palmer Dabbelt]

We have an implicit set of base behaviors that userspace depends on,
which are mostly defined in various ISA specifications.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 Documentation/riscv/hwprobe.rst       | 16 +++++++++++
 arch/riscv/include/asm/hwprobe.h      |  2 +-
 arch/riscv/include/uapi/asm/hwprobe.h |  7 +++++
 arch/riscv/kernel/sys_riscv.c         | 38 +++++++++++++++++++++++++++
 4 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index be9ebe4af3dc..b182fcf4cd30 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -31,3 +31,19 @@ The following keys are defined:
   specifications.
 * :RISCV_HWPROBE_KEY_MIMPLID:: Contains the value of :mimplid:, as per the ISA
   specifications.
+* :RISCV_HWPROBE_KEY_BASE_BEHAVIOR:: A bitmask containing the base user-visible
+  behavior that this kernel supports.  The following base user ABIs are defined:
+    * :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).
+* :RISCV_HWPROBE_KEY_IMA_EXT_0:: A bitmask containing the extensions that are
+  compatible with the :RISCV_HWPROBE_BASE_BEHAVIOR_IMA: base system behavior.
+    * :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.
+    * :RISCV_HWPROBE_IMA_C:: The C extension is supported, as defined by
+      version 2.2 of the RISC-V ISA manual.
diff --git a/arch/riscv/include/asm/hwprobe.h b/arch/riscv/include/asm/hwprobe.h
index 08d1c3bdd78a..7e52f1e1fe10 100644
--- a/arch/riscv/include/asm/hwprobe.h
+++ b/arch/riscv/include/asm/hwprobe.h
@@ -8,6 +8,6 @@
 
 #include <uapi/asm/hwprobe.h>
 
-#define RISCV_HWPROBE_MAX_KEY 2
+#define RISCV_HWPROBE_MAX_KEY 4
 
 #endif
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 88ef9e153637..07309376c6dc 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -19,6 +19,13 @@ struct riscv_hwprobe {
 #define RISCV_HWPROBE_KEY_MVENDORID	0
 #define RISCV_HWPROBE_KEY_MARCHID	1
 #define RISCV_HWPROBE_KEY_MIMPID	2
+#define RISCV_HWPROBE_KEY_BASE_BEHAVIOR	3
+#define		RISCV_HWPROBE_BASE_BEHAVIOR_IMA	(1 << 0)
+#define RISCV_HWPROBE_KEY_IMA_EXT_0	4
+#define		RISCV_HWPROBE_IMA_FD		(1 << 0)
+#define		RISCV_HWPROBE_IMA_C		(1 << 1)
 /* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
 
+
+
 #endif
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 2b6cb82c3491..337e3f2a17c8 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -9,6 +9,7 @@
 #include <asm/cacheflush.h>
 #include <asm/cpufeature.h>
 #include <asm/hwprobe.h>
+#include <asm/switch_to.h>
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
 #include <asm-generic/mman-common.h>
@@ -76,6 +77,11 @@ SYSCALL_DEFINE3(riscv_flush_icache, uintptr_t, start, uintptr_t, end,
 	return 0;
 }
 
+/*
+ * The hwprobe interface, for allowing userspace to probe to see which features
+ * are supported by the hardware.  See Documentation/riscv/hwprobe.rst for more
+ * details.
+ */
 static long set_hwprobe(struct riscv_hwprobe __user *pair, u64 key, u64 val)
 {
 	long ret;
@@ -158,6 +164,15 @@ long do_riscv_hwprobe(struct riscv_hwprobe __user *pairs, long pair_count,
 	if (!ret)
 		return -EFAULT;
 
+
+	/*
+	 * Userspace must provide at least one online CPU, without that there's
+	 * no way to define what is supported.
+	 */
+	cpumask_and(&cpus, &cpus, cpu_online_mask);
+	if (cpumask_empty(&cpus))
+		return -EINVAL;
+
 	out = 0;
 	k = key_offset;
 	while (out < pair_count && k < RISCV_HWPROBE_MAX_KEY) {
@@ -169,6 +184,29 @@ long do_riscv_hwprobe(struct riscv_hwprobe __user *pairs, long pair_count,
 		case RISCV_HWPROBE_KEY_MIMPID:
 			ret = hwprobe_mid(pairs + out, k, &cpus);
 			break;
+
+		/*
+		 * The kernel already assumes that the base single-letter ISA
+		 * extensions are supported on all harts, and only supports the
+		 * IMA base, so just cheat a bit here and tell that to
+		 * userspace.
+		 */
+		case RISCV_HWPROBE_KEY_BASE_BEHAVIOR:
+			ret = set_hwprobe(pairs + out, k,
+					  RISCV_HWPROBE_BASE_BEHAVIOR_IMA);
+			break;
+
+		case RISCV_HWPROBE_KEY_IMA_EXT_0:
+			{
+				u64 val = 0;
+
+				if (has_fpu())
+					val |= RISCV_HWPROBE_IMA_FD;
+				if (elf_hwcap & RISCV_ISA_EXT_c)
+					val |= RISCV_HWPROBE_IMA_C;
+				ret = set_hwprobe(pairs + out, k, val);
+			}
+			break;
 		}
 
 		if (ret < 0)
-- 
2.38.0


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

[PATCH v1 3/5] dt-bindings: Add RISC-V misaligned access performance

[Palmer Dabbelt]

This key allows device trees to specify the performance of misaligned
accesses to main memory regions from each CPU in the system.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 873dd12f6e89..832ae9101d05 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -83,6 +83,21 @@ properties:
       - rv64imac
       - rv64imafdc
 
+  riscv,misaligned-access-performance:
+    description:
+      Identifies the performance of misaligned memory accesses to main memory
+      regions.  There are three flavors of unaligned access performance: "emulated"
+      means that misaligned accesses are emulated via software and thus
+      extremely slow, "slow" means that misaligned accesses are supported by
+      hardware but still slower that aligned accesses sequences, and "fast"
+      means that misaligned accesses are as fast or faster than the
+      cooresponding aligned accesses sequences.
+    $ref: "/schemas/types.yaml#/definitions/string"
+    enum:
+      - emulated
+      - slow
+      - fast
+
   # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
   timebase-frequency: false
 
-- 
2.38.0


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

[PATCH v1 4/5] RISC-V: hwprobe: Support probing of misaligned accesss performance

[Palmer Dabbelt]

This allows userspace to select various routines to use based on the
performance of misaligned access on the target hardware.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 Documentation/riscv/hwprobe.rst       | 13 +++++++++++++
 arch/riscv/include/asm/cpufeature.h   |  2 ++
 arch/riscv/include/asm/hwprobe.h      |  2 +-
 arch/riscv/include/asm/smp.h          |  7 +++++++
 arch/riscv/include/uapi/asm/hwprobe.h |  7 +++++--
 arch/riscv/kernel/cpufeature.c        | 24 ++++++++++++++++++++++--
 arch/riscv/kernel/sys_riscv.c         | 22 ++++++++++++++++++++++
 7 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index b182fcf4cd30..f8aa9137d8aa 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -47,3 +47,16 @@ The following keys are defined:
       not minNum/maxNum") of the RISC-V ISA manual.
     * :RISCV_HWPROBE_IMA_C:: The C extension is supported, as defined by
       version 2.2 of the RISC-V ISA manual.
+* :RISCV_HWPROBE_KEY_PERF_0:: A bitmask that contains performance information
+  about the selected set of processors.
+    * :RISCV_HWPROBE_MISALIGNED_UNKNOWN:: The performance of misaligned
+      accesses is unknown.
+    * :RISCV_HWPROBE_MISALIGNED_EMULATED:: Misaligned accesses are emulated via
+      software, either in or below the kernel.  These accesses are always
+      extremely slow.
+    * :RISCV_HWPROBE_MISALIGNED_SLOW:: Misaligned accesses are supported in
+      hardware, but are slower than the cooresponding aligned accesses
+      sequences.
+    * :RISCV_HWPROBE_MISALIGNED_FAST:: Misaligned accesses are supported in
+      hardware and are faster than the cooresponding aligned accesses
+      sequences.
diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
index cbda062de9bd..54bdcf9a5049 100644
--- a/arch/riscv/include/asm/cpufeature.h
+++ b/arch/riscv/include/asm/cpufeature.h
@@ -18,4 +18,6 @@ struct riscv_cpuinfo {
 
 DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
 
+DECLARE_PER_CPU(long, misaligned_access_speed);
+
 #endif
diff --git a/arch/riscv/include/asm/hwprobe.h b/arch/riscv/include/asm/hwprobe.h
index 7e52f1e1fe10..4e45e33015bc 100644
--- a/arch/riscv/include/asm/hwprobe.h
+++ b/arch/riscv/include/asm/hwprobe.h
@@ -8,6 +8,6 @@
 
 #include <uapi/asm/hwprobe.h>
 
-#define RISCV_HWPROBE_MAX_KEY 4
+#define RISCV_HWPROBE_MAX_KEY 5
 
 #endif
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index d3443be7eedc..5d98836cc446 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -26,6 +26,13 @@ struct riscv_ipi_ops {
  */
 extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
 #define cpuid_to_hartid_map(cpu)    __cpuid_to_hartid_map[cpu]
+static inline long hartid_to_cpuid_map(unsigned long hartid) {
+	long i;
+	for (i = 0; i < NR_CPUS; ++i)
+		if (cpuid_to_hartid_map(i) == hartid)
+			return i;
+	return -1;
+}
 
 /* print IPI stats */
 void show_ipi_stats(struct seq_file *p, int prec);
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 07309376c6dc..e36b72f4e1af 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -24,8 +24,11 @@ struct riscv_hwprobe {
 #define RISCV_HWPROBE_KEY_IMA_EXT_0	4
 #define		RISCV_HWPROBE_IMA_FD		(1 << 0)
 #define		RISCV_HWPROBE_IMA_C		(1 << 1)
+#define RISCV_HWPROBE_KEY_CPUPERF_0	5
+#define		RISCV_HWPROBE_MISALIGNED_UNKNOWN	(0 << 0)
+#define		RISCV_HWPROBE_MISALIGNED_EMULATED	(1 << 0)
+#define		RISCV_HWPROBE_MISALIGNED_SLOW		(2 << 0)
+#define		RISCV_HWPROBE_MISALIGNED_FAST		(3 << 0)
 /* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
 
-
-
 #endif
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 553d755483ed..1599e40cd170 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -15,6 +15,7 @@
 #include <asm/cacheflush.h>
 #include <asm/errata_list.h>
 #include <asm/hwcap.h>
+#include <asm/hwprobe.h>
 #include <asm/patch.h>
 #include <asm/pgtable.h>
 #include <asm/processor.h>
@@ -31,6 +32,9 @@ static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
 __ro_after_init DEFINE_STATIC_KEY_ARRAY_FALSE(riscv_isa_ext_keys, RISCV_ISA_EXT_KEY_MAX);
 EXPORT_SYMBOL(riscv_isa_ext_keys);
 
+/* Performance information */
+DEFINE_PER_CPU(long, misaligned_access_speed);
+
 /**
  * riscv_isa_extension_base() - Get base extension word
  *
@@ -71,11 +75,11 @@ EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
 void __init riscv_fill_hwcap(void)
 {
 	struct device_node *node;
-	const char *isa;
+	const char *isa, *misaligned;
 	char print_str[NUM_ALPHA_EXTS + 1];
 	int i, j, rc;
 	static unsigned long isa2hwcap[256] = {0};
-	unsigned long hartid;
+	unsigned long hartid, cpu;
 
 	isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
 	isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
@@ -222,6 +226,22 @@ void __init riscv_fill_hwcap(void)
 			bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
 		else
 			bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+
+		/*
+		 * Check for the performance of misaligned accesses.
+		 */
+		cpu = hartid_to_cpuid_map(hartid);
+		if (cpu < 0)
+			continue;
+
+		if (of_property_read_string(node, "riscv,misaligned-access-performance", &misaligned)) {
+			if (strcmp(misaligned, "emulated") == 0)
+				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_EMULATED;
+			if (strcmp(misaligned, "slow") == 0)
+				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_SLOW;
+			if (strcmp(misaligned, "fast") == 0)
+				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_FAST;
+		}
 	}
 
 	/* We don't support systems with F but without D, so mask those out
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 337e3f2a17c8..fc9e8cd1589b 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -139,6 +139,24 @@ static long hwprobe_mid(struct riscv_hwprobe __user *pair, size_t key,
 	return set_hwprobe(pair, key, id);
 }
 
+static long hwprobe_misaligned(cpumask_t *cpus)
+{
+	long cpu, perf = -1;
+
+	for_each_cpu(cpu, cpus) {
+		long this_perf = per_cpu(misaligned_access_speed, cpu);
+		if (perf == -1)
+			perf = this_perf;
+
+		if (perf != this_perf)
+			perf = RISCV_HWPROBE_MISALIGNED_UNKNOWN;
+	}
+
+	if (perf == -1)
+		return RISCV_HWPROBE_MISALIGNED_UNKNOWN;
+	return perf;
+}
+
 static
 long do_riscv_hwprobe(struct riscv_hwprobe __user *pairs, long pair_count,
 		      long key_offset, long cpu_count,
@@ -207,6 +225,10 @@ long do_riscv_hwprobe(struct riscv_hwprobe __user *pairs, long pair_count,
 				ret = set_hwprobe(pairs + out, k, val);
 			}
 			break;
+
+		case RISCV_HWPROBE_KEY_CPUPERF_0:
+			set_hwprobe(pairs + out, k, hwprobe_misaligned(&cpus));
+			break;
 		}
 
 		if (ret < 0)
-- 
2.38.0


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

[PATCH v1 5/5] selftests: Test the new RISC-V hwprobe interface

[Palmer Dabbelt]

This adds a test for the recently added RISC-V interface for probing
hardware capabilities.  It happens to be the first selftest we have for
RISC-V, so I've added some infrastructure for those as well.  The build
stuff looks pretty straight-forward, but there's also  a tiny C library
to avoid coupling this to any userspace implementation.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
I'm not actually sure this tiny C library is a good idea, but the
toolchain I have locally doesn't have a functioning C library.
---
 tools/testing/selftests/Makefile              |   1 +
 tools/testing/selftests/riscv/Makefile        |  58 ++++++++++++++++++
 .../testing/selftests/riscv/hwprobe/Makefile  |  10 +++
 tools/testing/selftests/riscv/hwprobe/hwprobe | Bin 0 -> 75072 bytes
 .../testing/selftests/riscv/hwprobe/hwprobe.c |  49 +++++++++++++++
 .../selftests/riscv/hwprobe/sys_hwprobe.S     |  12 ++++
 tools/testing/selftests/riscv/libc.S          |  46 ++++++++++++++
 7 files changed, 176 insertions(+)
 create mode 100644 tools/testing/selftests/riscv/Makefile
 create mode 100644 tools/testing/selftests/riscv/hwprobe/Makefile
 create mode 100755 tools/testing/selftests/riscv/hwprobe/hwprobe
 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

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 10b34bb03bc1..9ff28a629f5b 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -56,6 +56,7 @@ TARGETS += pstore
 TARGETS += ptrace
 TARGETS += openat2
 TARGETS += resctrl
+TARGETS += riscv
 TARGETS += rlimits
 TARGETS += rseq
 TARGETS += rtc
diff --git a/tools/testing/selftests/riscv/Makefile b/tools/testing/selftests/riscv/Makefile
new file mode 100644
index 000000000000..32a72902d045
--- /dev/null
+++ b/tools/testing/selftests/riscv/Makefile
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0
+# Originally tools/testing/arm64/Makefile
+
+# When ARCH not overridden for crosscompiling, lookup machine
+ARCH ?= $(shell uname -m 2>/dev/null || echo not)
+
+ifneq (,$(filter $(ARCH),riscv))
+RISCV_SUBTARGETS ?= hwprobe
+else
+RISCV_SUBTARGETS :=
+endif
+
+CFLAGS := -Wall -O2 -g
+
+# A proper top_srcdir is needed by KSFT(lib.mk)
+top_srcdir = $(realpath ../../../../)
+
+# Additional include paths needed by kselftest.h and local headers
+CFLAGS += -I$(top_srcdir)/tools/testing/selftests/
+
+CFLAGS += $(KHDR_INCLUDES)
+
+export CFLAGS
+export top_srcdir
+
+all:
+	@for DIR in $(RISCV_SUBTARGETS); do				\
+		BUILD_TARGET=$(OUTPUT)/$$DIR;			\
+		mkdir -p $$BUILD_TARGET;			\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$DIR $@;		\
+	done
+
+install: all
+	@for DIR in $(RISCV_SUBTARGETS); do				\
+		BUILD_TARGET=$(OUTPUT)/$$DIR;			\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$DIR $@;		\
+	done
+
+run_tests: all
+	@for DIR in $(RISCV_SUBTARGETS); do				\
+		BUILD_TARGET=$(OUTPUT)/$$DIR;			\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$DIR $@;		\
+	done
+
+# Avoid any output on non riscv on emit_tests
+emit_tests: all
+	@for DIR in $(RISCV_SUBTARGETS); do				\
+		BUILD_TARGET=$(OUTPUT)/$$DIR;			\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$DIR $@;		\
+	done
+
+clean:
+	@for DIR in $(RISCV_SUBTARGETS); do				\
+		BUILD_TARGET=$(OUTPUT)/$$DIR;			\
+		$(MAKE) OUTPUT=$$BUILD_TARGET -C $$DIR $@;		\
+	done
+
+.PHONY: all clean install run_tests emit_tests
diff --git a/tools/testing/selftests/riscv/hwprobe/Makefile b/tools/testing/selftests/riscv/hwprobe/Makefile
new file mode 100644
index 000000000000..614501584803
--- /dev/null
+++ b/tools/testing/selftests/riscv/hwprobe/Makefile
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2021 ARM Limited
+# Originally tools/testing/arm64/abi/Makefile
+
+TEST_GEN_PROGS := hwprobe
+
+include ../../lib.mk
+
+$(OUTPUT)/hwprobe: hwprobe.c ../libc.S sys_hwprobe.S
+	$(CC) -o$@ $(CFLAGS) $(LDFLAGS) -nostdlib $^
diff --git a/tools/testing/selftests/riscv/hwprobe/hwprobe b/tools/testing/selftests/riscv/hwprobe/hwprobe
new file mode 100755
index 0000000000000000000000000000000000000000..6c37d3be12a9880d36a9d8fe9339be9e64c15efc
GIT binary patch
literal 75072
zcmeI0ZERcB8OP7L*Kdgv$7yJjQXmd=tV4^Pgb=a<Taq?Ovz2yh8rWLc<;HOwua527
zPM4szH0??Y0*Q*3vKI;1qzSQU+KZ-E(<H`+6*@GjlQx0G7o>qEO_~5rWtx!4p6A|k
z9OuRcY16*_kL2^5^FPmX&U1eE-g9j~G`f4tkW%Pkihm03Jz=`akQzAA>H7GoKO_c4
zkm`1^Nd&0xb2Qg+$Tc+Tma}SVZ9_`u={fE-HSV=t%1>M6=H$jX)GJq1-r9<&>&fw)
zt7viiqI0bsQVg`!aR#}4Qk;_zPo)yn`}^9v<rybVE%Rwcr78AN9CN9cr(Q=}%_Wh|
zOeeB4-PufTVX?cIDJ72#^mk_q1N}4cQa;|R*JnJuC(UD*5RY(|HHA)``qTNN9mgBb
zyftp?v}kmFF^Nov4pPIL$woy;_+o4QdA+FkU}dO7XY7u*IXe5V)rDoHv-xQ|YZdaD
zTsc+TDoSNLc}UEq>;lEalz(OUm^<G#kFMA2@#uQJ!F9Sj&*8&2esJ?YL};s69zXW=
zo6npclVdN8-gr82b>yA*M6BW5cyi-a-w)3`7HS@QDw%xxl6We8`q9V#@JjHn-@Wkh
z@;FB{kDaE7_ry@(^msCQ)fh=XJ}yU-*Z)hrRA?;!edcca<cX!Jzr1{G>h~`%OkKTj
zc<S8?=ewjh^^4`p?PSf~<;&-9r2a2YUT(jM`nR5X^`@RlAxD=--+RCF!zV*m{3S|P
zKL2DW7UkB-6K?jXK>!3m00ck)1V8`;KmY`45xDyCN}l!i)z1(8+wxidK}1FWhKs3w
zqbrLWlnpD}q3lLwwF#=mMHR1qA3mV;24!{pM=NeVBs;GER(<C;q4I?R0T2KI5C8!X
z009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH
z0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI
z5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X
z009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH
z0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI
z5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X
z009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH0T2KI5C8!X009sH
z0T2KI5CDPy7l9R3D)V<%TA$b$-?3wRY}<G$SI*~Sy}j|ic&}CH>*?$3>FvEOR_Onn
z5@TBP%=UTe8;%xo>JHO&Sai+0+Vy`^3gP-cq5KEddAfp{pO$d_FDd`VI{tsAnf*dK
z&LKZJUC)l}o!~}QF=Sw#x`qrLVq^G!>zLpYnFgOflPe3u7yLepA^*?FG`>ic*?CLa
zk%H%3^NeHszaryX=C%x#$%OBxDr&TZeoEGVD77TQ2dO3eN9?SKax)~F*hhu}3uNA+
zkLgt0Ggqs(xtpU(_|9_0&F06bl1=_GGG5^F2bTyz;1Uf*c)W=|0s4q7tTX1|y;Mco
zU#G5l?(O5j*QwhQ<$29>Zyt~27s^6LgPg$wJi-&C$Tyl1^13FLMeCrt3cR`VG$!Q%
zW0C5Ea!|_qWRH~h%U&tJX)KXw$sVy`wkl%Pn|$t*x32RRzN0j88}IiT&MPRyRx*5D
zujkd4snR#j_A4~<27Na2$O-M&%e^q&HkBKui<DJAIU$UW;~jLpwu*50i(xZD+xLr!
zHbUGY!d)S5`J06q+TLZ{(G~qdc%p4EOep=rjBM|ccXTzeWVBOu{YnZu3e6d6m7j^U
zh0V?_om1_tGD=PjY8kpQ8#l3k_zuUN?vyrZM#5oNkhE%3Tz+Y@_W11PiMBg8v)t^J
zTjhq}P{)JLV1#lA={Y&6mav>^=dft?2wl2e@|b+6jYl@PO#&??@AjH5+J1ueC}gXM
zQr;U{%*d7q?S!ABTG}x}>Zcp|P9B%?qewFw5(U$jveV=TZx?+E^f6?o(c+_qD$kRZ
zFHvRqrD!npjchhazhTM-8eCJGtoUWXe9&ox%%+9_2|?<!4Vi%kgB{FrL!+a+eIuX-
zLIG1ak)+55AG!Fo5;RRG#>WCpLS0_#I`gPwH>$uO2lBv1a&XtClY;wnQW)gS>(lHJ
zHz7T{vtE>jD(jJAI6f7nfo614GLNZU_?&*&EOKV%BKOQzr#85z4-tNt=<x-JGs;>Q
z!1y(d@W+8~T%?xZih=7V$ZX*ahiHDosby8|tVO$KD2A#z69=H1GpV%pKAMy>xrHaM
zm5JnA!Oh}jY6+*JEH0^o!EDg8I&-_Ty2ls4+Dsvj%4S3Kb1W5ow=B9{F%tQ?+<Dgb
zNMQf6VT?7tGV<EU<&lUO;oF&uT}&Sl<9nuJJ9=;TzS3gd^Y(P+u54kTe}>z|<lJ4w
zBLn@Jd3$yy8S75Ry7%_Qx@U9w?o!!K9_lU>^W{{soG*%kohg<?F;hw&vF5%_`gBSx
z<Vu-zE;SQN&e=s#n#&i<v5Lm8m3cdp6WM$&9doKRW0tir&|fvk{_YgqqFp3KvanDR
z+01k@J}DA&`T10$U}xu3#Y8qUo1!YWu$Z8?dA5`&r%L5aE}bZ)va{SSC7etXI#cE`
zJQ?eY-+H?!EtT{RXkO(JPyUZ9)XQ(7R7_-Y$?U>RDq)xA>#pMQ>rSU~sbVHs$!|^&
zmhNnJpg%q*;&F{-?PmDJ&i5vlpuTZ>)O{xp1a(tC5WXMD1JA8`#<l0cpl()q9wblw
zI-J&?2ZFPzSzMJ)sOHI4={u_V@TzoHH6N`=;;yRv10zbmN7;a$R?j5@dW$+sXXBqx
z(X%C9<5SyHO!{W`eofsJG51T~ng~<)#IrSZzqnXa4^*Dx>WNH#;n(>7YVtLVReQQ^
zKAuCd^@*C!_r6;G`czmuW;$P%)@s}{Me};m(dkP=jbe(H8Y<5dt)sWr(Kpo5>22*P
zynCPcV8tT~-f1m;ljB&MXD$D0$zSsPp6hax(qrm&bf%?>?^*Wm@LZQk(xapgb*#N!
zDMt@fzOGT%DJ80-bbW_B^PF<@knnl*?>Ty)^7YV}gsMjzef>O7*U?`feFJ@Q*3XiD
z&-~c&=XI%3RenP4XpQ^xH;%r3-B;@9m6MIm`Q)K5?>XFmdps|ui-&}@^Ba4H@1EEp
ztgr6dyJK|c)V@(`_r#vB43Cdm`-ew%k6OYS-@SKac(=88Y;1CLe?_&@+5EJfwF-GU
zEK|j;p7)hyP3|1tKWvSRj!*2dEaAN4gk_CPPFkaTc9LRQ)1{I{dQrW+=2CWn)HPvN
zYQ`?x!b;_4gou}x=F9dp*>cgfbGqf^P!RESZXrHrm+07@S;~>SYs*CuFQ&3Kiy~f5
zEtVbKo~J`U?ko^b=SfTE=jZ81D`~0eg|uZC?OZxl(%npMHm}?E^mH+GMEB_Rn9}Xp
zqCH>fP<mQtAKL9|KcCEI=<TV;i@CJhue$#KZF36+@{^#CM|}=!+vS;<eX9#Ue;=-_
z<aNA0ueI$_&ie6m--4?%bW@Yh2pzA_b#3*1&)?hGN5^+io6BwV;kk9ZKL547ft{*~
zH-A1S^xW*G-xJzCz#<iI{(Aj!8sj;gpSWc8^Q!Gd(yEKjQ)_oqgJbplmGey>;VNOy
zk&E8HKFRMPja@47G3szp4)kT&?W=liPl)?Sua4L6u~5|Y99$E<y1vfCR`L2eYxf})
z-=_s-_4?X=OT~NK#0eGugl9nSTg&`!iJnVqY@@BNy3GUJ>wCIR{9v2wIqC`Ubj6c(
z;*VY9dfK0|{&RKW-`?cL@1pVQqPc60{{dl7FaK@rZhXQu+P%U`%NOdz->cq_f2>5h
z4IQWLt18~(Cbn*NJ$~mI&~aLRgBo6q$KFx#!`e|<uP^sKh#k*u*SelBst02useIOH
ve){>P-_xtljuYutSNM+}Dwo`DrS`7R-<&GXUd2m@XKrvk|5l}O(;NREPvxm6

literal 0
HcmV?d00001

diff --git a/tools/testing/selftests/riscv/hwprobe/hwprobe.c b/tools/testing/selftests/riscv/hwprobe/hwprobe.c
new file mode 100644
index 000000000000..c2824a806975
--- /dev/null
+++ b/tools/testing/selftests/riscv/hwprobe/hwprobe.c
@@ -0,0 +1,49 @@
+#include <asm/hwprobe.h>
+
+/*
+ * Rather than relying on having a new enough libc to define this, just do it
+ * ourselves.  This way we don't need to be coupled to a new-enough libc to
+ * contain the call.
+ */
+long riscv_hwprobe(struct riscv_hwprobe *pairs, long pair_count,
+		   long key_offset, long cpu_count, unsigned long *cpus,
+		   unsigned long flags);
+
+int main(int argc, char **argv)
+{
+	struct riscv_hwprobe pairs[8];
+	unsigned long cpus;
+	long out;
+
+	/* Fake the CPU_SET ops. */
+	cpus = -1;
+
+	/*
+	 * Just run a basic test: pass enough pairs to get up to the base
+	 * behavior, and then check to make sure it's sane.
+	 */
+	out = riscv_hwprobe(pairs, 8, 0, 1, &cpus, 0);
+	if (out != 4)
+	  return -1;
+	for (long i = 0; i < out; ++i) {
+	  if (pairs[i].key != RISCV_HWPROBE_KEY_BASE_BEHAVIOR)
+	    continue;
+
+	  if (pairs[i].val & RISCV_HWPROBE_BASE_BEHAVIOR_IMA)
+	    continue;
+
+	  return -2;
+	}
+
+	/*
+	 * Check that offsets work by providing one that we know exists, and
+	 * checking to make sure the resultig pair is what we asked for.
+	 */
+	out = riscv_hwprobe(pairs, 1, RISCV_HWPROBE_KEY_BASE_BEHAVIOR, 1, &cpus, 0);
+	if (out != 1)
+	  return -3;
+	if (pairs[0].key != RISCV_HWPROBE_KEY_BASE_BEHAVIOR)
+	  return -4;
+
+	return 0;
+}
diff --git a/tools/testing/selftests/riscv/hwprobe/sys_hwprobe.S b/tools/testing/selftests/riscv/hwprobe/sys_hwprobe.S
new file mode 100644
index 000000000000..42f93dad3a67
--- /dev/null
+++ b/tools/testing/selftests/riscv/hwprobe/sys_hwprobe.S
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2022 Rivos, Inc
+
+.text
+.global riscv_hwprobe
+riscv_hwprobe:
+	# Put __NR_riscv_hwprobe in the syscall number register, then just shim
+	# back the kernel's return.  This doesn't do any sort of errno
+	# handling, the caller can deal with it.
+	li a7, 258
+	ecall
+	ret
diff --git a/tools/testing/selftests/riscv/libc.S b/tools/testing/selftests/riscv/libc.S
new file mode 100644
index 000000000000..b548f73c596d
--- /dev/null
+++ b/tools/testing/selftests/riscv/libc.S
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2022 Rivos, Inc
+# A C library
+
+#if __riscv_xlen == 64
+# define REG_S sd
+#else
+# define REG_S sw
+#endif
+
+.text
+.global _start
+_start:
+.option push
+.option norelax
+	la gp, __global_pointer$
+.option pop
+
+	la sp, stack
+
+	la t0, heap
+	la t1, brk
+	REG_S t0, 0(t1)
+
+	li a0, 0
+	li a1, 0
+
+	call main
+	
+	li a7, 93
+	ecall
+
+1:
+	j 1b
+
+.data
+brk:
+	.long 0
+
+.global heap
+heap:
+.rep 65536
+.byte 0
+.endr
+.global stack
+stack:
-- 
2.38.0


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

Re: [PATCH v1 1/5] RISC-V: Add a syscall for HW probing

[Christoph Hellwig]

probe is a very unfortunate name.  This doesn't probe anything, it
just reads out information.

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

Re: [PATCH v1 4/5] RISC-V: hwprobe: Support probing of misaligned accesss performance

[Heiko Stübner]

Am Donnerstag, 13. Oktober 2022, 18:35:50 CET schrieb Palmer Dabbelt:
> This allows userspace to select various routines to use based on the
> performance of misaligned access on the target hardware.
> 
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

[...]

> diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
> index cbda062de9bd..54bdcf9a5049 100644
> --- a/arch/riscv/include/asm/cpufeature.h
> +++ b/arch/riscv/include/asm/cpufeature.h
> @@ -18,4 +18,6 @@ struct riscv_cpuinfo {
>  
>  DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
>  
> +DECLARE_PER_CPU(long, misaligned_access_speed);

just my 2ct ... wouldn't it make sense to have struct riscv_cpuinfo
as the central instance for all cpu-related stuff, so
misaligned_access_speed could also be part of it?


> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 553d755483ed..1599e40cd170 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -222,6 +226,22 @@ void __init riscv_fill_hwcap(void)
>  			bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>  		else
>  			bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
> +
> +		/*
> +		 * Check for the performance of misaligned accesses.
> +		 */
> +		cpu = hartid_to_cpuid_map(hartid);
> +		if (cpu < 0)
> +			continue;
> +
> +		if (of_property_read_string(node, "riscv,misaligned-access-performance", &misaligned)) {

I think this wants a "!" in front :-) .

of_property_read_string() returns 0 on success, so running this
results in a nullptr right now.

> +			if (strcmp(misaligned, "emulated") == 0)
> +				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_EMULATED;
> +			if (strcmp(misaligned, "slow") == 0)
> +				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_SLOW;
> +			if (strcmp(misaligned, "fast") == 0)
> +				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_FAST;
> +		}
>  	}
>  
>  	/* We don't support systems with F but without D, so mask those out


Heiko



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

Re: [PATCH v1 4/5] RISC-V: hwprobe: Support probing of misaligned accesss performance

[Palmer Dabbelt]

On Tue, 29 Nov 2022 13:09:49 PST (-0800), heiko@sntech.de wrote:
> Am Donnerstag, 13. Oktober 2022, 18:35:50 CET schrieb Palmer Dabbelt:
>> This allows userspace to select various routines to use based on the
>> performance of misaligned access on the target hardware.
>>
>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>
> [...]
>
>> diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
>> index cbda062de9bd..54bdcf9a5049 100644
>> --- a/arch/riscv/include/asm/cpufeature.h
>> +++ b/arch/riscv/include/asm/cpufeature.h
>> @@ -18,4 +18,6 @@ struct riscv_cpuinfo {
>>
>>  DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
>>
>> +DECLARE_PER_CPU(long, misaligned_access_speed);
>
> just my 2ct ... wouldn't it make sense to have struct riscv_cpuinfo
> as the central instance for all cpu-related stuff, so
> misaligned_access_speed could also be part of it?

I remember going through this one a few times and ending up here despite 
some cleaner-looking ways of doing it.  That way does look cleaner, 
though, so I'll give it a shot and we'll see what happens...

>> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
>> index 553d755483ed..1599e40cd170 100644
>> --- a/arch/riscv/kernel/cpufeature.c
>> +++ b/arch/riscv/kernel/cpufeature.c
>> @@ -222,6 +226,22 @@ void __init riscv_fill_hwcap(void)
>>  			bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>>  		else
>>  			bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>> +
>> +		/*
>> +		 * Check for the performance of misaligned accesses.
>> +		 */
>> +		cpu = hartid_to_cpuid_map(hartid);
>> +		if (cpu < 0)
>> +			continue;
>> +
>> +		if (of_property_read_string(node, "riscv,misaligned-access-performance", &misaligned)) {
>
> I think this wants a "!" in front :-) .
>
> of_property_read_string() returns 0 on success, so running this
> results in a nullptr right now.

Thanks.  I'd not gotten around to actually running this so I bet it's 
broken in a bunch of ways.  Did you try it out?  I was really hoping to 
find some time to get at least the simple stuff in for this cycle, but 
too many things keep coming up.

>
>> +			if (strcmp(misaligned, "emulated") == 0)
>> +				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_EMULATED;
>> +			if (strcmp(misaligned, "slow") == 0)
>> +				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_SLOW;
>> +			if (strcmp(misaligned, "fast") == 0)
>> +				per_cpu(misaligned_access_speed, cpu) = RISCV_HWPROBE_MISALIGNED_FAST;
>> +		}
>>  	}
>>
>>  	/* We don't support systems with F but without D, so mask those out
>
>
> Heiko

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

Re: [PATCH v1 4/5] RISC-V: hwprobe: Support probing of misaligned accesss performance

[Heiko Stübner]

Am Dienstag, 29. November 2022, 22:18:18 CET schrieb Palmer Dabbelt:
> On Tue, 29 Nov 2022 13:09:49 PST (-0800), heiko@sntech.de wrote:
> > Am Donnerstag, 13. Oktober 2022, 18:35:50 CET schrieb Palmer Dabbelt:
> >> This allows userspace to select various routines to use based on the
> >> performance of misaligned access on the target hardware.
> >>
> >> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> >
> > [...]
> >
> >> diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
> >> index cbda062de9bd..54bdcf9a5049 100644
> >> --- a/arch/riscv/include/asm/cpufeature.h
> >> +++ b/arch/riscv/include/asm/cpufeature.h
> >> @@ -18,4 +18,6 @@ struct riscv_cpuinfo {
> >>
> >>  DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
> >>
> >> +DECLARE_PER_CPU(long, misaligned_access_speed);
> >
> > just my 2ct ... wouldn't it make sense to have struct riscv_cpuinfo
> > as the central instance for all cpu-related stuff, so
> > misaligned_access_speed could also be part of it?
> 
> I remember going through this one a few times and ending up here despite 
> some cleaner-looking ways of doing it.  That way does look cleaner, 
> though, so I'll give it a shot and we'll see what happens...
> 
> >> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> >> index 553d755483ed..1599e40cd170 100644
> >> --- a/arch/riscv/kernel/cpufeature.c
> >> +++ b/arch/riscv/kernel/cpufeature.c
> >> @@ -222,6 +226,22 @@ void __init riscv_fill_hwcap(void)
> >>  			bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
> >>  		else
> >>  			bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
> >> +
> >> +		/*
> >> +		 * Check for the performance of misaligned accesses.
> >> +		 */
> >> +		cpu = hartid_to_cpuid_map(hartid);
> >> +		if (cpu < 0)
> >> +			continue;
> >> +
> >> +		if (of_property_read_string(node, "riscv,misaligned-access-performance", &misaligned)) {
> >
> > I think this wants a "!" in front :-) .
> >
> > of_property_read_string() returns 0 on success, so running this
> > results in a nullptr right now.
> 
> Thanks.  I'd not gotten around to actually running this so I bet it's 
> broken in a bunch of ways.  Did you try it out?  I was really hoping to 
> find some time to get at least the simple stuff in for this cycle, but 
> too many things keep coming up.

I ran the code today, so bumped into the "!" issue.
I'm not yet "using" it, but that will come in the next days.

And no worries about that time-thingy, your series already provides
a nice pointer for the general direction to with things, so that is helpful
in its own right.

I will simply report any brokeness I find when it happens ;-) .


Heiko




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

Re: [PATCH v1 4/5] RISC-V: hwprobe: Support probing of misaligned accesss performance

[Palmer Dabbelt]

On Tue, 29 Nov 2022 14:10:02 PST (-0800), heiko@sntech.de wrote:
> Am Dienstag, 29. November 2022, 22:18:18 CET schrieb Palmer Dabbelt:
>> On Tue, 29 Nov 2022 13:09:49 PST (-0800), heiko@sntech.de wrote:
>> > Am Donnerstag, 13. Oktober 2022, 18:35:50 CET schrieb Palmer Dabbelt:
>> >> This allows userspace to select various routines to use based on the
>> >> performance of misaligned access on the target hardware.
>> >>
>> >> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>> >
>> > [...]
>> >
>> >> diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
>> >> index cbda062de9bd..54bdcf9a5049 100644
>> >> --- a/arch/riscv/include/asm/cpufeature.h
>> >> +++ b/arch/riscv/include/asm/cpufeature.h
>> >> @@ -18,4 +18,6 @@ struct riscv_cpuinfo {
>> >>
>> >>  DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
>> >>
>> >> +DECLARE_PER_CPU(long, misaligned_access_speed);
>> >
>> > just my 2ct ... wouldn't it make sense to have struct riscv_cpuinfo
>> > as the central instance for all cpu-related stuff, so
>> > misaligned_access_speed could also be part of it?
>>
>> I remember going through this one a few times and ending up here despite
>> some cleaner-looking ways of doing it.  That way does look cleaner,
>> though, so I'll give it a shot and we'll see what happens...
>>
>> >> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
>> >> index 553d755483ed..1599e40cd170 100644
>> >> --- a/arch/riscv/kernel/cpufeature.c
>> >> +++ b/arch/riscv/kernel/cpufeature.c
>> >> @@ -222,6 +226,22 @@ void __init riscv_fill_hwcap(void)
>> >>  			bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>> >>  		else
>> >>  			bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>> >> +
>> >> +		/*
>> >> +		 * Check for the performance of misaligned accesses.
>> >> +		 */
>> >> +		cpu = hartid_to_cpuid_map(hartid);
>> >> +		if (cpu < 0)
>> >> +			continue;
>> >> +
>> >> +		if (of_property_read_string(node, "riscv,misaligned-access-performance", &misaligned)) {
>> >
>> > I think this wants a "!" in front :-) .
>> >
>> > of_property_read_string() returns 0 on success, so running this
>> > results in a nullptr right now.
>>
>> Thanks.  I'd not gotten around to actually running this so I bet it's
>> broken in a bunch of ways.  Did you try it out?  I was really hoping to
>> find some time to get at least the simple stuff in for this cycle, but
>> too many things keep coming up.
>
> I ran the code today, so bumped into the "!" issue.
> I'm not yet "using" it, but that will come in the next days.
>
> And no worries about that time-thingy, your series already provides
> a nice pointer for the general direction to with things, so that is helpful
> in its own right.

I'm still worried about the release, as it's the last one before the 
glibc release and we'll need hooks there too.

> I will simply report any brokeness I find when it happens ;-) .

Awesome, thanks!

>
>
> Heiko

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

Re: [PATCH v1 0/5] RISC-V Hardware Probing User Interface

[Andrew Jones]

On Thu, Oct 13, 2022 at 09:35:46AM -0700, Palmer Dabbelt wrote:
> 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 se
> 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. 

Hi Palmer,

To throw my two cents into the penny jar, I'd vote for sysfs. It handles
the heterogeneous CPU case since cpu feature nodes can be hung off each
cpu node. It also avoids yet another encoding. If we enumerate extensions
and their properties then we need to maintain that enumeration in both
the kernel space and userspace. If, OTOH, we use sysfs node names for
the encoding, then, when we match the spec naming exactly, e.g.

 .../features/zicbom
 .../features/zihintpause
 .../features/sscofpmf

userspace can look for features by name. Userspace libraries can even
lead the kernel in development, since the encoding (the spec name) is
already agreed.

Properties of extensions are just sub-nodes, some with standard names,
like

 .../features/zicbom/major
 .../features/zicbom/minor

and others, which are cpu feature specific, like

 .../features/zicbom/block_size

I used 'features' in the above examples for the node name, rather than
'isa', since not all features map to isa extensions, but it should be
possible to fit non-isa features into the same framework.

Thanks,
drew


> 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.
> 
> I threw this together during the conferences so I would be surprised if
> it's not broken, but I figured it'd be best to just get something on the
> lists sooner rather that later.  Happy to have someone go fix my code,
> but the new uABI is really going to be the tricky bit here.  There's
> some test code included, but I haven't even booted a kernel with these
> patches so YMMV.
> 
> These are also up at kernel.org/palmer/linux/riscv-hwprobe-v1 in case
> that's easier for folks.
> 
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

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

Re: [PATCH v1 0/5] RISC-V Hardware Probing User Interface

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 5325 bytes --]

Hey!

Just bringing this up somewhere a bit more visible than the weekly pw
sync-up yoke!
I just got my VisionFive2 today & I see Heiko has just posted another
version of Zbb support series, right as I had started typing this in
fact, so I'm curious where we stand. There's gonna be quite a few
people with Zba/Zbb capable hardware soon by the looks of things, so
it'd be nice to have something we can point people at that actually
applies to recent kernels.

I know Palmer you said you'd do some work on it over Christmas, but
since that didn't materialise - are you still planning on spinning up a
v2?
Some thoughts on Drew's sysfs suggestion below would probably be useful
if you aren't.

Thanks,
Conor.





On Thu, Dec 01, 2022 at 05:06:14PM +0100, Andrew Jones wrote:
> On Thu, Oct 13, 2022 at 09:35:46AM -0700, Palmer Dabbelt wrote:
> > 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 se
> > 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. 
> 
> Hi Palmer,
> 
> To throw my two cents into the penny jar, I'd vote for sysfs. It handles
> the heterogeneous CPU case since cpu feature nodes can be hung off each
> cpu node. It also avoids yet another encoding. If we enumerate extensions
> and their properties then we need to maintain that enumeration in both
> the kernel space and userspace. If, OTOH, we use sysfs node names for
> the encoding, then, when we match the spec naming exactly, e.g.
> 
>  .../features/zicbom
>  .../features/zihintpause
>  .../features/sscofpmf
> 
> userspace can look for features by name. Userspace libraries can even
> lead the kernel in development, since the encoding (the spec name) is
> already agreed.
> 
> Properties of extensions are just sub-nodes, some with standard names,
> like
> 
>  .../features/zicbom/major
>  .../features/zicbom/minor
> 
> and others, which are cpu feature specific, like
> 
>  .../features/zicbom/block_size
> 
> I used 'features' in the above examples for the node name, rather than
> 'isa', since not all features map to isa extensions, but it should be
> possible to fit non-isa features into the same framework.
> 
> Thanks,
> drew
> 
> 
> > 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.
> > 
> > I threw this together during the conferences so I would be surprised if
> > it's not broken, but I figured it'd be best to just get something on the
> > lists sooner rather that later.  Happy to have someone go fix my code,
> > but the new uABI is really going to be the tricky bit here.  There's
> > some test code included, but I haven't even booted a kernel with these
> > patches so YMMV.
> > 
> > These are also up at kernel.org/palmer/linux/riscv-hwprobe-v1 in case
> > that's easier for folks.
> > 
> > 
> > 
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

[-- 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

Re: [PATCH v1 0/5] RISC-V Hardware Probing User Interface

[Heiko Stübner]

Hey,

Am Montag, 9. Januar 2023, 19:47:17 CET schrieb Conor Dooley:
> Hey!
> 
> Just bringing this up somewhere a bit more visible than the weekly pw
> sync-up yoke!
> I just got my VisionFive2 today & I see Heiko has just posted another
> version of Zbb support series, right as I had started typing this in
> fact, so I'm curious where we stand. There's gonna be quite a few
> people with Zba/Zbb capable hardware soon by the looks of things, so
> it'd be nice to have something we can point people at that actually
> applies to recent kernels.
> 
> I know Palmer you said you'd do some work on it over Christmas, but
> since that didn't materialise - are you still planning on spinning up a
> v2?
> Some thoughts on Drew's sysfs suggestion below would probably be useful
> if you aren't.

from my further optimization pov, I just rebased Palmer's v1 forward,
as I essentially only want the has-fast-unaligned property from it ;-) .

The series I posted today is essentially the basics for "everyone with zbb"
and I have a second part on top of that and Palmers hw-probing series
that then does the further case.

I do hope to get that finalized tomorrow or wednesday.


Heiko

> On Thu, Dec 01, 2022 at 05:06:14PM +0100, Andrew Jones wrote:
> > On Thu, Oct 13, 2022 at 09:35:46AM -0700, Palmer Dabbelt wrote:
> > > 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 se
> > > 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. 
> > 
> > Hi Palmer,
> > 
> > To throw my two cents into the penny jar, I'd vote for sysfs. It handles
> > the heterogeneous CPU case since cpu feature nodes can be hung off each
> > cpu node. It also avoids yet another encoding. If we enumerate extensions
> > and their properties then we need to maintain that enumeration in both
> > the kernel space and userspace. If, OTOH, we use sysfs node names for
> > the encoding, then, when we match the spec naming exactly, e.g.
> > 
> >  .../features/zicbom
> >  .../features/zihintpause
> >  .../features/sscofpmf
> > 
> > userspace can look for features by name. Userspace libraries can even
> > lead the kernel in development, since the encoding (the spec name) is
> > already agreed.
> > 
> > Properties of extensions are just sub-nodes, some with standard names,
> > like
> > 
> >  .../features/zicbom/major
> >  .../features/zicbom/minor
> > 
> > and others, which are cpu feature specific, like
> > 
> >  .../features/zicbom/block_size
> > 
> > I used 'features' in the above examples for the node name, rather than
> > 'isa', since not all features map to isa extensions, but it should be
> > possible to fit non-isa features into the same framework.
> > 
> > Thanks,
> > drew
> > 
> > 
> > > 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.
> > > 
> > > I threw this together during the conferences so I would be surprised if
> > > it's not broken, but I figured it'd be best to just get something on the
> > > lists sooner rather that later.  Happy to have someone go fix my code,
> > > but the new uABI is really going to be the tricky bit here.  There's
> > > some test code included, but I haven't even booted a kernel with these
> > > patches so YMMV.
> > > 
> > > These are also up at kernel.org/palmer/linux/riscv-hwprobe-v1 in case
> > > that's easier for folks.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > 
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 





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

Re: [PATCH v1 0/5] RISC-V Hardware Probing User Interface

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 6644 bytes --]

Hey Heiko,
I thought I replied yesterday but obviously not!

On Mon, Jan 09, 2023 at 08:50:36PM +0100, Heiko Stübner wrote:
> Hey,
> 
> Am Montag, 9. Januar 2023, 19:47:17 CET schrieb Conor Dooley:
> > Hey!
> > 
> > Just bringing this up somewhere a bit more visible than the weekly pw
> > sync-up yoke!
> > I just got my VisionFive2 today & I see Heiko has just posted another
> > version of Zbb support series, right as I had started typing this in
> > fact, so I'm curious where we stand. There's gonna be quite a few
> > people with Zba/Zbb capable hardware soon by the looks of things, so
> > it'd be nice to have something we can point people at that actually
> > applies to recent kernels.
> > 
> > I know Palmer you said you'd do some work on it over Christmas, but
> > since that didn't materialise - are you still planning on spinning up a
> > v2?
> > Some thoughts on Drew's sysfs suggestion below would probably be useful
> > if you aren't.
> 
> from my further optimization pov, I just rebased Palmer's v1 forward,
> as I essentially only want the has-fast-unaligned property from it ;-) .

IIRC the v1 didn't build? Did you manage to get it built & test it at
all?

> The series I posted today is essentially the basics for "everyone with zbb"
> and I have a second part on top of that and Palmers hw-probing series
> that then does the further case.
> 
> I do hope to get that finalized tomorrow or wednesday.

I was going to ask what the "second part" was, but I figure if that's
your timeline for it, I'll probably see the answer to that question soon
enough :)

Thanks,
Conor.




> > On Thu, Dec 01, 2022 at 05:06:14PM +0100, Andrew Jones wrote:
> > > On Thu, Oct 13, 2022 at 09:35:46AM -0700, Palmer Dabbelt wrote:
> > > > 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 se
> > > > 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. 
> > > 
> > > Hi Palmer,
> > > 
> > > To throw my two cents into the penny jar, I'd vote for sysfs. It handles
> > > the heterogeneous CPU case since cpu feature nodes can be hung off each
> > > cpu node. It also avoids yet another encoding. If we enumerate extensions
> > > and their properties then we need to maintain that enumeration in both
> > > the kernel space and userspace. If, OTOH, we use sysfs node names for
> > > the encoding, then, when we match the spec naming exactly, e.g.
> > > 
> > >  .../features/zicbom
> > >  .../features/zihintpause
> > >  .../features/sscofpmf
> > > 
> > > userspace can look for features by name. Userspace libraries can even
> > > lead the kernel in development, since the encoding (the spec name) is
> > > already agreed.
> > > 
> > > Properties of extensions are just sub-nodes, some with standard names,
> > > like
> > > 
> > >  .../features/zicbom/major
> > >  .../features/zicbom/minor
> > > 
> > > and others, which are cpu feature specific, like
> > > 
> > >  .../features/zicbom/block_size
> > > 
> > > I used 'features' in the above examples for the node name, rather than
> > > 'isa', since not all features map to isa extensions, but it should be
> > > possible to fit non-isa features into the same framework.
> > > 
> > > Thanks,
> > > drew
> > > 
> > > 
> > > > 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.
> > > > 
> > > > I threw this together during the conferences so I would be surprised if
> > > > it's not broken, but I figured it'd be best to just get something on the
> > > > lists sooner rather that later.  Happy to have someone go fix my code,
> > > > but the new uABI is really going to be the tricky bit here.  There's
> > > > some test code included, but I haven't even booted a kernel with these
> > > > patches so YMMV.
> > > > 
> > > > These are also up at kernel.org/palmer/linux/riscv-hwprobe-v1 in case
> > > > that's easier for folks.
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > linux-riscv mailing list
> > > > linux-riscv@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > 
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > 
> 
> 
> 
> 

[-- 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