[RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
CSR to switch the memory consistency model at run-time from RVWMO to TSO
(and back). The active consistency model can therefore be switched on a
per-hart base and managed by the kernel on a per-process/thread base.

This patch implements basic Ssdtso support and adds a prctl API on top
so that user-space processes can switch to a stronger memory consistency
model (than the kernel was written for) at run-time.

I am not sure if other architectures support switching the memory
consistency model at run-time, but designing the prctl API in an
arch-independent way allows reusing it in the future.

The patchset also comes with a short documentation of the prctl API.

This series is based on the second draft of the Ssdtso specification
which was published recently on an RVI list:
  https://lists.riscv.org/g/tech-arch-review/message/183
Note, that the Ssdtso specification is in development state
(i.e., not frozen or even ratified) which is also the reason
why I marked the series as RFC.

One aspect that is not covered in this patchset is virtualization.
It is planned to add virtualization support in a later version.
Hints/suggestions on how to implement this part are very much
appreciated.

Christoph Müllner (5):
  RISC-V: Add basic Ssdtso support
  RISC-V: Expose Ssdtso via hwprobe API
  uapi: prctl: Add new prctl call to set/get the memory consistency
    model
  RISC-V: Implement prctl call to set/get the memory consistency model
  RISC-V: selftests: Add DTSO tests

 Documentation/arch/riscv/hwprobe.rst          |  3 +
 .../mm/dynamic-memory-consistency-model.rst   | 76 ++++++++++++++++++
 arch/riscv/Kconfig                            | 10 +++
 arch/riscv/include/asm/csr.h                  |  1 +
 arch/riscv/include/asm/dtso.h                 | 74 ++++++++++++++++++
 arch/riscv/include/asm/hwcap.h                |  1 +
 arch/riscv/include/asm/processor.h            |  8 ++
 arch/riscv/include/asm/switch_to.h            |  3 +
 arch/riscv/include/uapi/asm/hwprobe.h         |  1 +
 arch/riscv/kernel/Makefile                    |  1 +
 arch/riscv/kernel/cpufeature.c                |  1 +
 arch/riscv/kernel/dtso.c                      | 33 ++++++++
 arch/riscv/kernel/process.c                   |  4 +
 arch/riscv/kernel/sys_riscv.c                 |  1 +
 include/uapi/linux/prctl.h                    |  5 ++
 kernel/sys.c                                  | 12 +++
 tools/testing/selftests/riscv/Makefile        |  2 +-
 tools/testing/selftests/riscv/dtso/.gitignore |  1 +
 tools/testing/selftests/riscv/dtso/Makefile   | 11 +++
 tools/testing/selftests/riscv/dtso/dtso.c     | 77 +++++++++++++++++++
 20 files changed, 324 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/mm/dynamic-memory-consistency-model.rst
 create mode 100644 arch/riscv/include/asm/dtso.h
 create mode 100644 arch/riscv/kernel/dtso.c
 create mode 100644 tools/testing/selftests/riscv/dtso/.gitignore
 create mode 100644 tools/testing/selftests/riscv/dtso/Makefile
 create mode 100644 tools/testing/selftests/riscv/dtso/dtso.c

-- 
2.41.0

[RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
CSR to switch the memory consistency model at run-time from RVWMO to TSO
(and back). The active consistency model can therefore be switched on a
per-hart base and managed by the kernel on a per-process/thread base.

This patch implements basic Ssdtso support and adds a prctl API on top
so that user-space processes can switch to a stronger memory consistency
model (than the kernel was written for) at run-time.

I am not sure if other architectures support switching the memory
consistency model at run-time, but designing the prctl API in an
arch-independent way allows reusing it in the future.

The patchset also comes with a short documentation of the prctl API.

This series is based on the second draft of the Ssdtso specification
which was published recently on an RVI list:
  https://lists.riscv.org/g/tech-arch-review/message/183
Note, that the Ssdtso specification is in development state
(i.e., not frozen or even ratified) which is also the reason
why I marked the series as RFC.

One aspect that is not covered in this patchset is virtualization.
It is planned to add virtualization support in a later version.
Hints/suggestions on how to implement this part are very much
appreciated.

Christoph Müllner (5):
  RISC-V: Add basic Ssdtso support
  RISC-V: Expose Ssdtso via hwprobe API
  uapi: prctl: Add new prctl call to set/get the memory consistency
    model
  RISC-V: Implement prctl call to set/get the memory consistency model
  RISC-V: selftests: Add DTSO tests

 Documentation/arch/riscv/hwprobe.rst          |  3 +
 .../mm/dynamic-memory-consistency-model.rst   | 76 ++++++++++++++++++
 arch/riscv/Kconfig                            | 10 +++
 arch/riscv/include/asm/csr.h                  |  1 +
 arch/riscv/include/asm/dtso.h                 | 74 ++++++++++++++++++
 arch/riscv/include/asm/hwcap.h                |  1 +
 arch/riscv/include/asm/processor.h            |  8 ++
 arch/riscv/include/asm/switch_to.h            |  3 +
 arch/riscv/include/uapi/asm/hwprobe.h         |  1 +
 arch/riscv/kernel/Makefile                    |  1 +
 arch/riscv/kernel/cpufeature.c                |  1 +
 arch/riscv/kernel/dtso.c                      | 33 ++++++++
 arch/riscv/kernel/process.c                   |  4 +
 arch/riscv/kernel/sys_riscv.c                 |  1 +
 include/uapi/linux/prctl.h                    |  5 ++
 kernel/sys.c                                  | 12 +++
 tools/testing/selftests/riscv/Makefile        |  2 +-
 tools/testing/selftests/riscv/dtso/.gitignore |  1 +
 tools/testing/selftests/riscv/dtso/Makefile   | 11 +++
 tools/testing/selftests/riscv/dtso/dtso.c     | 77 +++++++++++++++++++
 20 files changed, 324 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/mm/dynamic-memory-consistency-model.rst
 create mode 100644 arch/riscv/include/asm/dtso.h
 create mode 100644 arch/riscv/kernel/dtso.c
 create mode 100644 tools/testing/selftests/riscv/dtso/.gitignore
 create mode 100644 tools/testing/selftests/riscv/dtso/Makefile
 create mode 100644 tools/testing/selftests/riscv/dtso/dtso.c

-- 
2.41.0


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

[RFC PATCH 1/5] RISC-V: Add basic Ssdtso support

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

Ssdtso is a RISC-V ISA extension, which allows to switch the memory
consistency model from RVWMO to TSO (and back) at runtime.
The active model is controlled by a DTSO bit in the {m,h,s}envcfg CSRs
(per-hart state).

TSO is a stronger memory ordering than RVWMO, which means that
executing software that was written for RVWMO can also run under TSO
without causing memory consistency issues.
Since RVWMO is the default model, switching to TSO is safe.

The patch introduces Ssdtso basic support:
* define the relevant bits
* register the the extension in hwcap/cpufeatures
* extend thread_struct to keep the state across context switches
* add the relevant code to store/restore the DTSO state

Following the pattern of existing code, this patch also introduces
a Kconfig symbol ('RISCV_ISA_SSDTSO') to disable Ssdtso support.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 arch/riscv/Kconfig                 | 10 ++++
 arch/riscv/include/asm/csr.h       |  1 +
 arch/riscv/include/asm/dtso.h      | 74 ++++++++++++++++++++++++++++++
 arch/riscv/include/asm/hwcap.h     |  1 +
 arch/riscv/include/asm/processor.h |  1 +
 arch/riscv/include/asm/switch_to.h |  3 ++
 arch/riscv/kernel/cpufeature.c     |  1 +
 arch/riscv/kernel/process.c        |  4 ++
 8 files changed, 95 insertions(+)
 create mode 100644 arch/riscv/include/asm/dtso.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 95a2a06acc6a..c62718fa8e7f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -457,6 +457,16 @@ config RISCV_ISA_C
 
 	  If you don't know what to do here, say Y.
 
+config RISCV_ISA_SSDTSO
+	bool "Ssdtso extension support for dynamic TSO memory ordering"
+	default y
+	help
+	  Adds support to dynamically detect the presence of the Ssdtso
+	  ISA-extension and allows user-space processes to activate/deactivate
+	  the TSO memory ordering model at run-time.
+
+	  If you don't know what to do here, say Y.
+
 config RISCV_ISA_SVNAPOT
 	bool "Svnapot extension support for supervisor mode NAPOT pages"
 	depends on 64BIT && MMU
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 306a19a5509c..2689ad6b2b60 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -194,6 +194,7 @@
 /* xENVCFG flags */
 #define ENVCFG_STCE			(_AC(1, ULL) << 63)
 #define ENVCFG_PBMTE			(_AC(1, ULL) << 62)
+#define ENVCFG_DTSO			(_AC(1, UL) << 8)
 #define ENVCFG_CBZE			(_AC(1, UL) << 7)
 #define ENVCFG_CBCFE			(_AC(1, UL) << 6)
 #define ENVCFG_CBIE_SHIFT		4
diff --git a/arch/riscv/include/asm/dtso.h b/arch/riscv/include/asm/dtso.h
new file mode 100644
index 000000000000..f8a758c45e05
--- /dev/null
+++ b/arch/riscv/include/asm/dtso.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2023 Christoph Muellner <christoph.muellner@vrull.eu>
+ */
+
+#ifndef __ASM_RISCV_DTSO_H
+#define __ASM_RISCV_DTSO_H
+
+#ifdef CONFIG_RISCV_ISA_SSDTSO
+
+#include <linux/sched/task_stack.h>
+#include <asm/cpufeature.h>
+#include <asm/csr.h>
+
+static __always_inline bool has_dtso(void)
+{
+	return riscv_has_extension_unlikely(RISCV_ISA_EXT_SSDTSO);
+}
+
+static inline bool dtso_is_enabled(void)
+{
+	if (has_dtso())
+		return csr_read(CSR_SENVCFG) & ENVCFG_DTSO;
+	return 0;
+}
+
+static inline void dtso_disable(void)
+{
+	if (has_dtso())
+		csr_clear(CSR_SENVCFG, ENVCFG_DTSO);
+}
+
+static inline void dtso_enable(void)
+{
+	if (has_dtso())
+		csr_set(CSR_SENVCFG, ENVCFG_DTSO);
+}
+
+static inline void dtso_save(struct task_struct *task)
+{
+	task->thread.dtso_ena = dtso_is_enabled();
+}
+
+static inline void dtso_restore(struct task_struct *task)
+{
+	if (task->thread.dtso_ena)
+		dtso_enable();
+	else
+		dtso_disable();
+}
+
+static inline void __switch_to_dtso(struct task_struct *prev,
+				    struct task_struct *next)
+{
+	struct pt_regs *regs;
+
+	regs = task_pt_regs(prev);
+	dtso_save(prev);
+	dtso_restore(next);
+}
+
+#else /* ! CONFIG_RISCV_ISA_SSDTSO */
+
+static __always_inline bool has_dtso(void) { return false; }
+static __always_inline bool dtso_is_enabled(void) { return false; }
+#define dtso_disable() do { } while (0)
+#define dtso_enable() do { } while (0)
+#define dtso_save(task) do { } while (0)
+#define dtso_restore(task) do { } while (0)
+#define __switch_to_dtso(prev, next) do { } while (0)
+
+#endif /* CONFIG_RISCV_ISA_SSDTSO */
+
+#endif /* ! __ASM_RISCV_DTSO_H */
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 06d30526ef3b..cbf924d6dfb7 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -57,6 +57,7 @@
 #define RISCV_ISA_EXT_ZIHPM		42
 #define RISCV_ISA_EXT_SMSTATEEN		43
 #define RISCV_ISA_EXT_ZICOND		44
+#define RISCV_ISA_EXT_SSDTSO		45
 
 #define RISCV_ISA_EXT_MAX		64
 
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index f19f861cda54..79cc5e6377b8 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -84,6 +84,7 @@ struct thread_struct {
 	unsigned long vstate_ctrl;
 	struct __riscv_v_ext_state vstate;
 	unsigned long align_ctl;
+	bool dtso_ena; /* Dynamic TSO enable */
 };
 
 /* Whitelist the fstate from the task_struct for hardened usercopy */
diff --git a/arch/riscv/include/asm/switch_to.h b/arch/riscv/include/asm/switch_to.h
index f90d8e42f3c7..f07180a3b533 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -9,6 +9,7 @@
 #include <linux/jump_label.h>
 #include <linux/sched/task_stack.h>
 #include <asm/vector.h>
+#include <asm/dtso.h>
 #include <asm/cpufeature.h>
 #include <asm/processor.h>
 #include <asm/ptrace.h>
@@ -81,6 +82,8 @@ do {							\
 		__switch_to_fpu(__prev, __next);	\
 	if (has_vector())					\
 		__switch_to_vector(__prev, __next);	\
+	if (has_dtso())					\
+		__switch_to_dtso(__prev, __next);	\
 	((last) = __switch_to(__prev, __next));		\
 } while (0)
 
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index b3785ffc1570..381ba02689ca 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -181,6 +181,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
 	__RISCV_ISA_EXT_DATA(smstateen, RISCV_ISA_EXT_SMSTATEEN),
 	__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
 	__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
+	__RISCV_ISA_EXT_DATA(ssdtso, RISCV_ISA_EXT_SSDTSO),
 	__RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
 	__RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
 	__RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 4f21d970a129..65462b675740 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -172,6 +172,10 @@ void flush_thread(void)
 	kfree(current->thread.vstate.datap);
 	memset(&current->thread.vstate, 0, sizeof(struct __riscv_v_ext_state));
 #endif
+#ifdef CONFIG_RISCV_ISA_SSDTSO
+	/* Reset DTSO state */
+	current->thread.dtso_ena = false;
+#endif
 }
 
 void arch_release_task_struct(struct task_struct *tsk)
-- 
2.41.0

[RFC PATCH 1/5] RISC-V: Add basic Ssdtso support

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

Ssdtso is a RISC-V ISA extension, which allows to switch the memory
consistency model from RVWMO to TSO (and back) at runtime.
The active model is controlled by a DTSO bit in the {m,h,s}envcfg CSRs
(per-hart state).

TSO is a stronger memory ordering than RVWMO, which means that
executing software that was written for RVWMO can also run under TSO
without causing memory consistency issues.
Since RVWMO is the default model, switching to TSO is safe.

The patch introduces Ssdtso basic support:
* define the relevant bits
* register the the extension in hwcap/cpufeatures
* extend thread_struct to keep the state across context switches
* add the relevant code to store/restore the DTSO state

Following the pattern of existing code, this patch also introduces
a Kconfig symbol ('RISCV_ISA_SSDTSO') to disable Ssdtso support.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 arch/riscv/Kconfig                 | 10 ++++
 arch/riscv/include/asm/csr.h       |  1 +
 arch/riscv/include/asm/dtso.h      | 74 ++++++++++++++++++++++++++++++
 arch/riscv/include/asm/hwcap.h     |  1 +
 arch/riscv/include/asm/processor.h |  1 +
 arch/riscv/include/asm/switch_to.h |  3 ++
 arch/riscv/kernel/cpufeature.c     |  1 +
 arch/riscv/kernel/process.c        |  4 ++
 8 files changed, 95 insertions(+)
 create mode 100644 arch/riscv/include/asm/dtso.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 95a2a06acc6a..c62718fa8e7f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -457,6 +457,16 @@ config RISCV_ISA_C
 
 	  If you don't know what to do here, say Y.
 
+config RISCV_ISA_SSDTSO
+	bool "Ssdtso extension support for dynamic TSO memory ordering"
+	default y
+	help
+	  Adds support to dynamically detect the presence of the Ssdtso
+	  ISA-extension and allows user-space processes to activate/deactivate
+	  the TSO memory ordering model at run-time.
+
+	  If you don't know what to do here, say Y.
+
 config RISCV_ISA_SVNAPOT
 	bool "Svnapot extension support for supervisor mode NAPOT pages"
 	depends on 64BIT && MMU
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 306a19a5509c..2689ad6b2b60 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -194,6 +194,7 @@
 /* xENVCFG flags */
 #define ENVCFG_STCE			(_AC(1, ULL) << 63)
 #define ENVCFG_PBMTE			(_AC(1, ULL) << 62)
+#define ENVCFG_DTSO			(_AC(1, UL) << 8)
 #define ENVCFG_CBZE			(_AC(1, UL) << 7)
 #define ENVCFG_CBCFE			(_AC(1, UL) << 6)
 #define ENVCFG_CBIE_SHIFT		4
diff --git a/arch/riscv/include/asm/dtso.h b/arch/riscv/include/asm/dtso.h
new file mode 100644
index 000000000000..f8a758c45e05
--- /dev/null
+++ b/arch/riscv/include/asm/dtso.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2023 Christoph Muellner <christoph.muellner@vrull.eu>
+ */
+
+#ifndef __ASM_RISCV_DTSO_H
+#define __ASM_RISCV_DTSO_H
+
+#ifdef CONFIG_RISCV_ISA_SSDTSO
+
+#include <linux/sched/task_stack.h>
+#include <asm/cpufeature.h>
+#include <asm/csr.h>
+
+static __always_inline bool has_dtso(void)
+{
+	return riscv_has_extension_unlikely(RISCV_ISA_EXT_SSDTSO);
+}
+
+static inline bool dtso_is_enabled(void)
+{
+	if (has_dtso())
+		return csr_read(CSR_SENVCFG) & ENVCFG_DTSO;
+	return 0;
+}
+
+static inline void dtso_disable(void)
+{
+	if (has_dtso())
+		csr_clear(CSR_SENVCFG, ENVCFG_DTSO);
+}
+
+static inline void dtso_enable(void)
+{
+	if (has_dtso())
+		csr_set(CSR_SENVCFG, ENVCFG_DTSO);
+}
+
+static inline void dtso_save(struct task_struct *task)
+{
+	task->thread.dtso_ena = dtso_is_enabled();
+}
+
+static inline void dtso_restore(struct task_struct *task)
+{
+	if (task->thread.dtso_ena)
+		dtso_enable();
+	else
+		dtso_disable();
+}
+
+static inline void __switch_to_dtso(struct task_struct *prev,
+				    struct task_struct *next)
+{
+	struct pt_regs *regs;
+
+	regs = task_pt_regs(prev);
+	dtso_save(prev);
+	dtso_restore(next);
+}
+
+#else /* ! CONFIG_RISCV_ISA_SSDTSO */
+
+static __always_inline bool has_dtso(void) { return false; }
+static __always_inline bool dtso_is_enabled(void) { return false; }
+#define dtso_disable() do { } while (0)
+#define dtso_enable() do { } while (0)
+#define dtso_save(task) do { } while (0)
+#define dtso_restore(task) do { } while (0)
+#define __switch_to_dtso(prev, next) do { } while (0)
+
+#endif /* CONFIG_RISCV_ISA_SSDTSO */
+
+#endif /* ! __ASM_RISCV_DTSO_H */
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 06d30526ef3b..cbf924d6dfb7 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -57,6 +57,7 @@
 #define RISCV_ISA_EXT_ZIHPM		42
 #define RISCV_ISA_EXT_SMSTATEEN		43
 #define RISCV_ISA_EXT_ZICOND		44
+#define RISCV_ISA_EXT_SSDTSO		45
 
 #define RISCV_ISA_EXT_MAX		64
 
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index f19f861cda54..79cc5e6377b8 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -84,6 +84,7 @@ struct thread_struct {
 	unsigned long vstate_ctrl;
 	struct __riscv_v_ext_state vstate;
 	unsigned long align_ctl;
+	bool dtso_ena; /* Dynamic TSO enable */
 };
 
 /* Whitelist the fstate from the task_struct for hardened usercopy */
diff --git a/arch/riscv/include/asm/switch_to.h b/arch/riscv/include/asm/switch_to.h
index f90d8e42f3c7..f07180a3b533 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -9,6 +9,7 @@
 #include <linux/jump_label.h>
 #include <linux/sched/task_stack.h>
 #include <asm/vector.h>
+#include <asm/dtso.h>
 #include <asm/cpufeature.h>
 #include <asm/processor.h>
 #include <asm/ptrace.h>
@@ -81,6 +82,8 @@ do {							\
 		__switch_to_fpu(__prev, __next);	\
 	if (has_vector())					\
 		__switch_to_vector(__prev, __next);	\
+	if (has_dtso())					\
+		__switch_to_dtso(__prev, __next);	\
 	((last) = __switch_to(__prev, __next));		\
 } while (0)
 
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index b3785ffc1570..381ba02689ca 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -181,6 +181,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
 	__RISCV_ISA_EXT_DATA(smstateen, RISCV_ISA_EXT_SMSTATEEN),
 	__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
 	__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
+	__RISCV_ISA_EXT_DATA(ssdtso, RISCV_ISA_EXT_SSDTSO),
 	__RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
 	__RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
 	__RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 4f21d970a129..65462b675740 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -172,6 +172,10 @@ void flush_thread(void)
 	kfree(current->thread.vstate.datap);
 	memset(&current->thread.vstate, 0, sizeof(struct __riscv_v_ext_state));
 #endif
+#ifdef CONFIG_RISCV_ISA_SSDTSO
+	/* Reset DTSO state */
+	current->thread.dtso_ena = false;
+#endif
 }
 
 void arch_release_task_struct(struct task_struct *tsk)
-- 
2.41.0


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

[RFC PATCH 2/5] RISC-V: Expose Ssdtso via hwprobe API

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

This patch adds Ssdtso to the list of extensions which
are announced to user-space using te hwprobe API.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 Documentation/arch/riscv/hwprobe.rst  | 3 +++
 arch/riscv/include/uapi/asm/hwprobe.h | 1 +
 arch/riscv/kernel/sys_riscv.c         | 1 +
 3 files changed, 5 insertions(+)

diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 7b2384de471f..8de3349e0ca2 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -80,6 +80,9 @@ The following keys are defined:
   * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
        ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
 
+  * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Ssdtso extension is supported, as
+       in version v1.0-draft2 of the corresponding extension.
+
 * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
   information about the selected set of processors.
 
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index b659ffcfcdb4..ed450c64e6b2 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -30,6 +30,7 @@ struct riscv_hwprobe {
 #define		RISCV_HWPROBE_EXT_ZBB		(1 << 4)
 #define		RISCV_HWPROBE_EXT_ZBS		(1 << 5)
 #define		RISCV_HWPROBE_EXT_ZICBOZ	(1 << 6)
+#define		RISCV_HWPROBE_EXT_SSDTSO	(1 << 7)
 #define RISCV_HWPROBE_KEY_CPUPERF_0	5
 #define		RISCV_HWPROBE_MISALIGNED_UNKNOWN	(0 << 0)
 #define		RISCV_HWPROBE_MISALIGNED_EMULATED	(1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index c712037dbe10..c654f43b9699 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -162,6 +162,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
 		EXT_KEY(ZBB);
 		EXT_KEY(ZBS);
 		EXT_KEY(ZICBOZ);
+		EXT_KEY(SSDTSO);
 #undef EXT_KEY
 	}
 
-- 
2.41.0

[RFC PATCH 2/5] RISC-V: Expose Ssdtso via hwprobe API

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

This patch adds Ssdtso to the list of extensions which
are announced to user-space using te hwprobe API.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 Documentation/arch/riscv/hwprobe.rst  | 3 +++
 arch/riscv/include/uapi/asm/hwprobe.h | 1 +
 arch/riscv/kernel/sys_riscv.c         | 1 +
 3 files changed, 5 insertions(+)

diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 7b2384de471f..8de3349e0ca2 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -80,6 +80,9 @@ The following keys are defined:
   * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
        ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
 
+  * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Ssdtso extension is supported, as
+       in version v1.0-draft2 of the corresponding extension.
+
 * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
   information about the selected set of processors.
 
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index b659ffcfcdb4..ed450c64e6b2 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -30,6 +30,7 @@ struct riscv_hwprobe {
 #define		RISCV_HWPROBE_EXT_ZBB		(1 << 4)
 #define		RISCV_HWPROBE_EXT_ZBS		(1 << 5)
 #define		RISCV_HWPROBE_EXT_ZICBOZ	(1 << 6)
+#define		RISCV_HWPROBE_EXT_SSDTSO	(1 << 7)
 #define RISCV_HWPROBE_KEY_CPUPERF_0	5
 #define		RISCV_HWPROBE_MISALIGNED_UNKNOWN	(0 << 0)
 #define		RISCV_HWPROBE_MISALIGNED_EMULATED	(1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index c712037dbe10..c654f43b9699 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -162,6 +162,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
 		EXT_KEY(ZBB);
 		EXT_KEY(ZBS);
 		EXT_KEY(ZICBOZ);
+		EXT_KEY(SSDTSO);
 #undef EXT_KEY
 	}
 
-- 
2.41.0


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

[RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

Some ISAs have a weak default memory consistency model and allow to switch
to a more strict model at runtime. This patch adds calls to the prctl
interface which allow to get and set the current memory consistency
model.

The implementation follows the way other prctl calls are implemented by
disabling them unless arch-specific code provides the relevant macros.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 .../mm/dynamic-memory-consistency-model.rst   | 58 +++++++++++++++++++
 include/uapi/linux/prctl.h                    |  3 +
 kernel/sys.c                                  | 12 ++++
 3 files changed, 73 insertions(+)
 create mode 100644 Documentation/mm/dynamic-memory-consistency-model.rst

diff --git a/Documentation/mm/dynamic-memory-consistency-model.rst b/Documentation/mm/dynamic-memory-consistency-model.rst
new file mode 100644
index 000000000000..21675b41ec84
--- /dev/null
+++ b/Documentation/mm/dynamic-memory-consistency-model.rst
@@ -0,0 +1,58 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================================
+Dynamic memory consistency model
+================================
+
+This document gives an overview of the userspace interface to change memory
+consistency model at run-time.
+
+
+What is a memory consistency model?
+===================================
+
+The memory consistency model is a set of guarantees a CPU architecture
+provides about (re-)ordering memory accesses. Each architecture defines
+its own model and set of rules within that, which are carefully specified.
+The provided guarantees have consequences for the microarchitectures (e.g.,
+some memory consistency models allow reordering stores after loads) and
+the software executed within this model (memory consistency models that
+allow reordering memory accesses provide memory barrier instructions
+to enforce additional guarantees when needed explicitly).
+
+Details about the architecture-independent memory consistency model abstraction
+in the Linux kernel and the use of the different types of memory barriers
+can be found here:
+
+	Documentation/memory-barriers.txt
+
+Two models can be in a weaker/stronger relation. I.e., a consistency
+model A is weaker/stronger than another model B if A provides a subset/superset
+of the constraints that B provides.
+
+Some architectures define more than one memory consistency model.
+On such architectures, switching the memory consistency model at run-time
+to a stronger one is possible because software written for the weaker model is
+compatible with the constraints of the stronger model.
+
+If two models are not in a weaker/stronger relation, switching between
+them will violate the consistency assumptions that the software was
+written under (i.e., causing subtle bugs that are very hard to debug).
+
+User API via prctl
+==================
+
+Two prctl calls are defined to get/set the active memory consistency model:
+
+* prctl(PR_GET_MEMORY_CONSISTENCY_MODEL)
+
+    Returns the active memory consistency model for the calling process/thread.
+    If the architecture does not support dynamic memory consistency models,
+    then -1 is returned, and errno is set to EINVAL.
+
+* prctl(PR_SET_MEMORY_CONSISTENCY_MODEL, unsigned long new_model)
+
+    Switches the memory consistency model for the calling process/thread
+    to the given model. If the architecture does not support dynamic
+    memory consistency models or does not support the provided model, then
+    -1 is returned, and errno is set to EINVAL.
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 370ed14b1ae0..579662731eaa 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -306,4 +306,7 @@ struct prctl_mm_map {
 # define PR_RISCV_V_VSTATE_CTRL_NEXT_MASK	0xc
 # define PR_RISCV_V_VSTATE_CTRL_MASK		0x1f
 
+#define PR_SET_MEMORY_CONSISTENCY_MODEL		71
+#define PR_GET_MEMORY_CONSISTENCY_MODEL		72
+
 #endif /* _LINUX_PRCTL_H */
diff --git a/kernel/sys.c b/kernel/sys.c
index e219fcfa112d..a8a217a10767 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -146,6 +146,12 @@
 #ifndef RISCV_V_GET_CONTROL
 # define RISCV_V_GET_CONTROL()		(-EINVAL)
 #endif
+#ifndef SET_MEMORY_CONSISTENCY_MODEL
+# define SET_MEMORY_CONSISTENCY_MODEL	(-EINVAL)
+#endif
+#ifndef GET_MEMORY_CONSISTENCY_MODEL
+# define GET_MEMORY_CONSISTENCY_MODEL	(-EINVAL)
+#endif
 
 /*
  * this is where the system-wide overflow UID and GID are defined, for
@@ -2743,6 +2749,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 	case PR_RISCV_V_GET_CONTROL:
 		error = RISCV_V_GET_CONTROL();
 		break;
+	case PR_SET_MEMORY_CONSISTENCY_MODEL:
+		error = SET_MEMORY_CONSISTENCY_MODEL(arg2);
+		break;
+	case PR_GET_MEMORY_CONSISTENCY_MODEL:
+		error = GET_MEMORY_CONSISTENCY_MODEL();
+		break;
 	default:
 		error = -EINVAL;
 		break;
-- 
2.41.0

[RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

Some ISAs have a weak default memory consistency model and allow to switch
to a more strict model at runtime. This patch adds calls to the prctl
interface which allow to get and set the current memory consistency
model.

The implementation follows the way other prctl calls are implemented by
disabling them unless arch-specific code provides the relevant macros.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 .../mm/dynamic-memory-consistency-model.rst   | 58 +++++++++++++++++++
 include/uapi/linux/prctl.h                    |  3 +
 kernel/sys.c                                  | 12 ++++
 3 files changed, 73 insertions(+)
 create mode 100644 Documentation/mm/dynamic-memory-consistency-model.rst

diff --git a/Documentation/mm/dynamic-memory-consistency-model.rst b/Documentation/mm/dynamic-memory-consistency-model.rst
new file mode 100644
index 000000000000..21675b41ec84
--- /dev/null
+++ b/Documentation/mm/dynamic-memory-consistency-model.rst
@@ -0,0 +1,58 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================================
+Dynamic memory consistency model
+================================
+
+This document gives an overview of the userspace interface to change memory
+consistency model at run-time.
+
+
+What is a memory consistency model?
+===================================
+
+The memory consistency model is a set of guarantees a CPU architecture
+provides about (re-)ordering memory accesses. Each architecture defines
+its own model and set of rules within that, which are carefully specified.
+The provided guarantees have consequences for the microarchitectures (e.g.,
+some memory consistency models allow reordering stores after loads) and
+the software executed within this model (memory consistency models that
+allow reordering memory accesses provide memory barrier instructions
+to enforce additional guarantees when needed explicitly).
+
+Details about the architecture-independent memory consistency model abstraction
+in the Linux kernel and the use of the different types of memory barriers
+can be found here:
+
+	Documentation/memory-barriers.txt
+
+Two models can be in a weaker/stronger relation. I.e., a consistency
+model A is weaker/stronger than another model B if A provides a subset/superset
+of the constraints that B provides.
+
+Some architectures define more than one memory consistency model.
+On such architectures, switching the memory consistency model at run-time
+to a stronger one is possible because software written for the weaker model is
+compatible with the constraints of the stronger model.
+
+If two models are not in a weaker/stronger relation, switching between
+them will violate the consistency assumptions that the software was
+written under (i.e., causing subtle bugs that are very hard to debug).
+
+User API via prctl
+==================
+
+Two prctl calls are defined to get/set the active memory consistency model:
+
+* prctl(PR_GET_MEMORY_CONSISTENCY_MODEL)
+
+    Returns the active memory consistency model for the calling process/thread.
+    If the architecture does not support dynamic memory consistency models,
+    then -1 is returned, and errno is set to EINVAL.
+
+* prctl(PR_SET_MEMORY_CONSISTENCY_MODEL, unsigned long new_model)
+
+    Switches the memory consistency model for the calling process/thread
+    to the given model. If the architecture does not support dynamic
+    memory consistency models or does not support the provided model, then
+    -1 is returned, and errno is set to EINVAL.
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 370ed14b1ae0..579662731eaa 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -306,4 +306,7 @@ struct prctl_mm_map {
 # define PR_RISCV_V_VSTATE_CTRL_NEXT_MASK	0xc
 # define PR_RISCV_V_VSTATE_CTRL_MASK		0x1f
 
+#define PR_SET_MEMORY_CONSISTENCY_MODEL		71
+#define PR_GET_MEMORY_CONSISTENCY_MODEL		72
+
 #endif /* _LINUX_PRCTL_H */
diff --git a/kernel/sys.c b/kernel/sys.c
index e219fcfa112d..a8a217a10767 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -146,6 +146,12 @@
 #ifndef RISCV_V_GET_CONTROL
 # define RISCV_V_GET_CONTROL()		(-EINVAL)
 #endif
+#ifndef SET_MEMORY_CONSISTENCY_MODEL
+# define SET_MEMORY_CONSISTENCY_MODEL	(-EINVAL)
+#endif
+#ifndef GET_MEMORY_CONSISTENCY_MODEL
+# define GET_MEMORY_CONSISTENCY_MODEL	(-EINVAL)
+#endif
 
 /*
  * this is where the system-wide overflow UID and GID are defined, for
@@ -2743,6 +2749,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 	case PR_RISCV_V_GET_CONTROL:
 		error = RISCV_V_GET_CONTROL();
 		break;
+	case PR_SET_MEMORY_CONSISTENCY_MODEL:
+		error = SET_MEMORY_CONSISTENCY_MODEL(arg2);
+		break;
+	case PR_GET_MEMORY_CONSISTENCY_MODEL:
+		error = GET_MEMORY_CONSISTENCY_MODEL();
+		break;
 	default:
 		error = -EINVAL;
 		break;
-- 
2.41.0


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

[RFC PATCH 4/5] RISC-V: Implement prctl call to set/get the memory consistency model

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

We can use the PR_{S,G}ET_MEMORY_CONSISTENCY_MODEL prctl calls to change
the memory consistency model at run-time if we have Ssdtso.
This patch registers RISCV_WMO and RISCV_TSO as valid arguments
for these prctl calls and implements the glue code to switch
between these.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 .../mm/dynamic-memory-consistency-model.rst   | 18 ++++++++++
 arch/riscv/include/asm/processor.h            |  7 ++++
 arch/riscv/kernel/Makefile                    |  1 +
 arch/riscv/kernel/dtso.c                      | 33 +++++++++++++++++++
 include/uapi/linux/prctl.h                    |  2 ++
 5 files changed, 61 insertions(+)
 create mode 100644 arch/riscv/kernel/dtso.c

diff --git a/Documentation/mm/dynamic-memory-consistency-model.rst b/Documentation/mm/dynamic-memory-consistency-model.rst
index 21675b41ec84..4a6107a4b71f 100644
--- a/Documentation/mm/dynamic-memory-consistency-model.rst
+++ b/Documentation/mm/dynamic-memory-consistency-model.rst
@@ -56,3 +56,21 @@ Two prctl calls are defined to get/set the active memory consistency model:
     to the given model. If the architecture does not support dynamic
     memory consistency models or does not support the provided model, then
     -1 is returned, and errno is set to EINVAL.
+
+Supported memory consistency models
+===================================
+
+This section defines the memory consistency models which are supported
+by the prctl interface.
+
+RISC-V
+------
+
+RISC-V uses RVWMO (RISC-V weak memory ordering) as default memory consistency
+model. TSO (total store ordering) is another specified model and provides
+additional ordering guarantees. Switching from RVWMO to TSO (and back) is
+possible when the Ssdtso extension is available.
+
+* :c:macro:`PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO`: RISC-V weak memory ordering (default).
+
+* :c:macro:`PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO`: RISC-V total store ordering.
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index 79cc5e6377b8..b0c19ddb2cfb 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -146,6 +146,13 @@ extern int set_unalign_ctl(struct task_struct *tsk, unsigned int val);
 #define GET_UNALIGN_CTL(tsk, addr)	get_unalign_ctl((tsk), (addr))
 #define SET_UNALIGN_CTL(tsk, val)	set_unalign_ctl((tsk), (val))
 
+#ifdef CONFIG_RISCV_ISA_SSDTSO
+#define SET_MEMORY_CONSISTENCY_MODEL(arg)	dtso_set_memory_ordering(arg)
+#define GET_MEMORY_CONSISTENCY_MODEL()		dtso_get_memory_ordering()
+extern int dtso_set_memory_consistency_model(unsigned long arg);
+extern int dtso_get_memory_consistency_model(void);
+#endif /* CONIG_RISCV_ISA_SSDTSO */
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_RISCV_PROCESSOR_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index fee22a3d1b53..17cf74ac8e21 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMU) += vdso.o vdso/
 obj-$(CONFIG_RISCV_MISALIGNED)	+= traps_misaligned.o
 obj-$(CONFIG_FPU)		+= fpu.o
 obj-$(CONFIG_RISCV_ISA_V)	+= vector.o
+obj-$(CONFIG_RISCV_ISA_SSDTSO)	+= dtso.o
 obj-$(CONFIG_SMP)		+= smpboot.o
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_SMP)		+= cpu_ops.o
diff --git a/arch/riscv/kernel/dtso.c b/arch/riscv/kernel/dtso.c
new file mode 100644
index 000000000000..fcf7e2e80362
--- /dev/null
+++ b/arch/riscv/kernel/dtso.c
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2023 Christoph Muellner <christoph.muellner@vrull.eu>
+ */
+
+#include <linux/export.h>
+#include <linux/prctl.h>
+#include <asm/dtso.h>
+
+int riscv_set_memory_consistency_model(unsigned long arg)
+{
+	switch (arg) {
+	case PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO:
+		dtso_disable();
+		break;
+	case PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO:
+		if (!has_dtso())
+			return -EINVAL;
+		dtso_enable();
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+int riscv_get_memory_consistency_model(void)
+{
+	if (has_dtso() && dtso_is_enabled())
+		return PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO;
+	return PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO;
+}
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 579662731eaa..20264bdc3092 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -308,5 +308,7 @@ struct prctl_mm_map {
 
 #define PR_SET_MEMORY_CONSISTENCY_MODEL		71
 #define PR_GET_MEMORY_CONSISTENCY_MODEL		72
+# define PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO	1
+# define PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO	2
 
 #endif /* _LINUX_PRCTL_H */
-- 
2.41.0

[RFC PATCH 4/5] RISC-V: Implement prctl call to set/get the memory consistency model

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

We can use the PR_{S,G}ET_MEMORY_CONSISTENCY_MODEL prctl calls to change
the memory consistency model at run-time if we have Ssdtso.
This patch registers RISCV_WMO and RISCV_TSO as valid arguments
for these prctl calls and implements the glue code to switch
between these.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 .../mm/dynamic-memory-consistency-model.rst   | 18 ++++++++++
 arch/riscv/include/asm/processor.h            |  7 ++++
 arch/riscv/kernel/Makefile                    |  1 +
 arch/riscv/kernel/dtso.c                      | 33 +++++++++++++++++++
 include/uapi/linux/prctl.h                    |  2 ++
 5 files changed, 61 insertions(+)
 create mode 100644 arch/riscv/kernel/dtso.c

diff --git a/Documentation/mm/dynamic-memory-consistency-model.rst b/Documentation/mm/dynamic-memory-consistency-model.rst
index 21675b41ec84..4a6107a4b71f 100644
--- a/Documentation/mm/dynamic-memory-consistency-model.rst
+++ b/Documentation/mm/dynamic-memory-consistency-model.rst
@@ -56,3 +56,21 @@ Two prctl calls are defined to get/set the active memory consistency model:
     to the given model. If the architecture does not support dynamic
     memory consistency models or does not support the provided model, then
     -1 is returned, and errno is set to EINVAL.
+
+Supported memory consistency models
+===================================
+
+This section defines the memory consistency models which are supported
+by the prctl interface.
+
+RISC-V
+------
+
+RISC-V uses RVWMO (RISC-V weak memory ordering) as default memory consistency
+model. TSO (total store ordering) is another specified model and provides
+additional ordering guarantees. Switching from RVWMO to TSO (and back) is
+possible when the Ssdtso extension is available.
+
+* :c:macro:`PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO`: RISC-V weak memory ordering (default).
+
+* :c:macro:`PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO`: RISC-V total store ordering.
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index 79cc5e6377b8..b0c19ddb2cfb 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -146,6 +146,13 @@ extern int set_unalign_ctl(struct task_struct *tsk, unsigned int val);
 #define GET_UNALIGN_CTL(tsk, addr)	get_unalign_ctl((tsk), (addr))
 #define SET_UNALIGN_CTL(tsk, val)	set_unalign_ctl((tsk), (val))
 
+#ifdef CONFIG_RISCV_ISA_SSDTSO
+#define SET_MEMORY_CONSISTENCY_MODEL(arg)	dtso_set_memory_ordering(arg)
+#define GET_MEMORY_CONSISTENCY_MODEL()		dtso_get_memory_ordering()
+extern int dtso_set_memory_consistency_model(unsigned long arg);
+extern int dtso_get_memory_consistency_model(void);
+#endif /* CONIG_RISCV_ISA_SSDTSO */
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_RISCV_PROCESSOR_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index fee22a3d1b53..17cf74ac8e21 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMU) += vdso.o vdso/
 obj-$(CONFIG_RISCV_MISALIGNED)	+= traps_misaligned.o
 obj-$(CONFIG_FPU)		+= fpu.o
 obj-$(CONFIG_RISCV_ISA_V)	+= vector.o
+obj-$(CONFIG_RISCV_ISA_SSDTSO)	+= dtso.o
 obj-$(CONFIG_SMP)		+= smpboot.o
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_SMP)		+= cpu_ops.o
diff --git a/arch/riscv/kernel/dtso.c b/arch/riscv/kernel/dtso.c
new file mode 100644
index 000000000000..fcf7e2e80362
--- /dev/null
+++ b/arch/riscv/kernel/dtso.c
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2023 Christoph Muellner <christoph.muellner@vrull.eu>
+ */
+
+#include <linux/export.h>
+#include <linux/prctl.h>
+#include <asm/dtso.h>
+
+int riscv_set_memory_consistency_model(unsigned long arg)
+{
+	switch (arg) {
+	case PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO:
+		dtso_disable();
+		break;
+	case PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO:
+		if (!has_dtso())
+			return -EINVAL;
+		dtso_enable();
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+int riscv_get_memory_consistency_model(void)
+{
+	if (has_dtso() && dtso_is_enabled())
+		return PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO;
+	return PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO;
+}
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 579662731eaa..20264bdc3092 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -308,5 +308,7 @@ struct prctl_mm_map {
 
 #define PR_SET_MEMORY_CONSISTENCY_MODEL		71
 #define PR_GET_MEMORY_CONSISTENCY_MODEL		72
+# define PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO	1
+# define PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO	2
 
 #endif /* _LINUX_PRCTL_H */
-- 
2.41.0


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

[RFC PATCH 5/5] RISC-V: selftests: Add DTSO tests

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

This patch tests the dynamic memory consistency model prctl() behaviour
on RISC-V. It does not depend on CONFIG_RISCV_ISA_SSDTSO or the availability
of Ssdtso, but will test other aspects if these are not given.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 tools/testing/selftests/riscv/Makefile        |  2 +-
 tools/testing/selftests/riscv/dtso/.gitignore |  1 +
 tools/testing/selftests/riscv/dtso/Makefile   | 11 +++
 tools/testing/selftests/riscv/dtso/dtso.c     | 77 +++++++++++++++++++
 4 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/riscv/dtso/.gitignore
 create mode 100644 tools/testing/selftests/riscv/dtso/Makefile
 create mode 100644 tools/testing/selftests/riscv/dtso/dtso.c

diff --git a/tools/testing/selftests/riscv/Makefile b/tools/testing/selftests/riscv/Makefile
index 4a9ff515a3a0..1421c21841f9 100644
--- a/tools/testing/selftests/riscv/Makefile
+++ b/tools/testing/selftests/riscv/Makefile
@@ -5,7 +5,7 @@
 ARCH ?= $(shell uname -m 2>/dev/null || echo not)
 
 ifneq (,$(filter $(ARCH),riscv))
-RISCV_SUBTARGETS ?= hwprobe vector mm
+RISCV_SUBTARGETS ?= dtso hwprobe vector mm
 else
 RISCV_SUBTARGETS :=
 endif
diff --git a/tools/testing/selftests/riscv/dtso/.gitignore b/tools/testing/selftests/riscv/dtso/.gitignore
new file mode 100644
index 000000000000..217d01679115
--- /dev/null
+++ b/tools/testing/selftests/riscv/dtso/.gitignore
@@ -0,0 +1 @@
+dtso
diff --git a/tools/testing/selftests/riscv/dtso/Makefile b/tools/testing/selftests/riscv/dtso/Makefile
new file mode 100644
index 000000000000..a1ffbdd3da85
--- /dev/null
+++ b/tools/testing/selftests/riscv/dtso/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2023 VRULL
+
+CFLAGS += -I$(top_srcdir)/tools/include
+
+TEST_GEN_PROGS := dtso
+
+include ../../lib.mk
+
+$(OUTPUT)/dtso: dtso.c ../hwprobe/sys_hwprobe.S
+	$(CC) -static -o$@ $(CFLAGS) $(LDFLAGS) $^
diff --git a/tools/testing/selftests/riscv/dtso/dtso.c b/tools/testing/selftests/riscv/dtso/dtso.c
new file mode 100644
index 000000000000..b9ca33ca6551
--- /dev/null
+++ b/tools/testing/selftests/riscv/dtso/dtso.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* dtso - used for functional tests of memory consistency model switching
+ * at run-time.
+ *
+ * Copyright (c) 2023 Christoph Muellner <christoph.muellner@vrull.eu>
+ */
+
+#include <sys/prctl.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "../hwprobe/hwprobe.h"
+#include "../../kselftest_harness.h"
+
+/*
+ * We have the following cases:
+ * 1) DTSO support disabed in the kernel config:
+ *    - Ssdtso is not detected
+ *    - {G,S}ET_MEMORY_CONSISTENCY_MODEL fails with EINVAL
+ * 2) DTSO support enabled and Ssdtso not available:
+ *    - Ssdtso is not detected
+ *    - {G,S}ET_MEMORY_CONSISTENCY_MODEL works for WMO and fails for TSO with EINVAL:
+ * 3) DTSO support enabled and Ssdtso available
+ *    - Ssdtso is detected
+ *    - {G,S}ET_MEMORY_CONSISTENCY_MODEL works for WMO and TSO
+ */
+
+TEST(dtso)
+{
+	struct riscv_hwprobe pair;
+	int ret;
+	bool ssdtso_configured;
+	bool ssdtso_available;
+
+	ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+	if (ret < 0) {
+		ASSERT_EQ(errno, EINVAL);
+		ssdtso_configured = false;
+	} else {
+		ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO ||
+			    ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+		ssdtso_configured = true;
+	}
+
+	pair.key = RISCV_HWPROBE_KEY_IMA_EXT_0;
+	ret = riscv_hwprobe(&pair, 1, 0, NULL, 0);
+	ASSERT_GE(ret, 0);
+	ASSERT_EQ(pair.key, RISCV_HWPROBE_KEY_IMA_EXT_0);
+	ssdtso_available = !!(pair.value & RISCV_HWPROBE_EXT_SSDTSO);
+
+	if (ssdtso_configured) {
+		ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+		ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO ||
+			    ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+
+		if (ssdtso_available) {
+			ret = prctl(PR_SET_MEMORY_CONSISTENCY_MODEL,
+				    PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+			ASSERT_EQ(ret, 0);
+			ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+			ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+		} else {
+			ksft_test_result_skip("Ssdtso not available\n");
+		}
+
+		ret = prctl(PR_SET_MEMORY_CONSISTENCY_MODEL,
+			    PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO);
+		ASSERT_EQ(ret, 0);
+		ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+		ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO);
+	} else {
+		ASSERT_EQ(ssdtso_available, false);
+		ksft_test_result_skip("Ssdtso not configured\n");
+	}
+}
+
+TEST_HARNESS_MAIN
-- 
2.41.0

[RFC PATCH 5/5] RISC-V: selftests: Add DTSO tests

[Christoph Muellner]

From: Christoph Müllner <christoph.muellner@vrull.eu>

This patch tests the dynamic memory consistency model prctl() behaviour
on RISC-V. It does not depend on CONFIG_RISCV_ISA_SSDTSO or the availability
of Ssdtso, but will test other aspects if these are not given.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 tools/testing/selftests/riscv/Makefile        |  2 +-
 tools/testing/selftests/riscv/dtso/.gitignore |  1 +
 tools/testing/selftests/riscv/dtso/Makefile   | 11 +++
 tools/testing/selftests/riscv/dtso/dtso.c     | 77 +++++++++++++++++++
 4 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/riscv/dtso/.gitignore
 create mode 100644 tools/testing/selftests/riscv/dtso/Makefile
 create mode 100644 tools/testing/selftests/riscv/dtso/dtso.c

diff --git a/tools/testing/selftests/riscv/Makefile b/tools/testing/selftests/riscv/Makefile
index 4a9ff515a3a0..1421c21841f9 100644
--- a/tools/testing/selftests/riscv/Makefile
+++ b/tools/testing/selftests/riscv/Makefile
@@ -5,7 +5,7 @@
 ARCH ?= $(shell uname -m 2>/dev/null || echo not)
 
 ifneq (,$(filter $(ARCH),riscv))
-RISCV_SUBTARGETS ?= hwprobe vector mm
+RISCV_SUBTARGETS ?= dtso hwprobe vector mm
 else
 RISCV_SUBTARGETS :=
 endif
diff --git a/tools/testing/selftests/riscv/dtso/.gitignore b/tools/testing/selftests/riscv/dtso/.gitignore
new file mode 100644
index 000000000000..217d01679115
--- /dev/null
+++ b/tools/testing/selftests/riscv/dtso/.gitignore
@@ -0,0 +1 @@
+dtso
diff --git a/tools/testing/selftests/riscv/dtso/Makefile b/tools/testing/selftests/riscv/dtso/Makefile
new file mode 100644
index 000000000000..a1ffbdd3da85
--- /dev/null
+++ b/tools/testing/selftests/riscv/dtso/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2023 VRULL
+
+CFLAGS += -I$(top_srcdir)/tools/include
+
+TEST_GEN_PROGS := dtso
+
+include ../../lib.mk
+
+$(OUTPUT)/dtso: dtso.c ../hwprobe/sys_hwprobe.S
+	$(CC) -static -o$@ $(CFLAGS) $(LDFLAGS) $^
diff --git a/tools/testing/selftests/riscv/dtso/dtso.c b/tools/testing/selftests/riscv/dtso/dtso.c
new file mode 100644
index 000000000000..b9ca33ca6551
--- /dev/null
+++ b/tools/testing/selftests/riscv/dtso/dtso.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* dtso - used for functional tests of memory consistency model switching
+ * at run-time.
+ *
+ * Copyright (c) 2023 Christoph Muellner <christoph.muellner@vrull.eu>
+ */
+
+#include <sys/prctl.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "../hwprobe/hwprobe.h"
+#include "../../kselftest_harness.h"
+
+/*
+ * We have the following cases:
+ * 1) DTSO support disabed in the kernel config:
+ *    - Ssdtso is not detected
+ *    - {G,S}ET_MEMORY_CONSISTENCY_MODEL fails with EINVAL
+ * 2) DTSO support enabled and Ssdtso not available:
+ *    - Ssdtso is not detected
+ *    - {G,S}ET_MEMORY_CONSISTENCY_MODEL works for WMO and fails for TSO with EINVAL:
+ * 3) DTSO support enabled and Ssdtso available
+ *    - Ssdtso is detected
+ *    - {G,S}ET_MEMORY_CONSISTENCY_MODEL works for WMO and TSO
+ */
+
+TEST(dtso)
+{
+	struct riscv_hwprobe pair;
+	int ret;
+	bool ssdtso_configured;
+	bool ssdtso_available;
+
+	ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+	if (ret < 0) {
+		ASSERT_EQ(errno, EINVAL);
+		ssdtso_configured = false;
+	} else {
+		ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO ||
+			    ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+		ssdtso_configured = true;
+	}
+
+	pair.key = RISCV_HWPROBE_KEY_IMA_EXT_0;
+	ret = riscv_hwprobe(&pair, 1, 0, NULL, 0);
+	ASSERT_GE(ret, 0);
+	ASSERT_EQ(pair.key, RISCV_HWPROBE_KEY_IMA_EXT_0);
+	ssdtso_available = !!(pair.value & RISCV_HWPROBE_EXT_SSDTSO);
+
+	if (ssdtso_configured) {
+		ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+		ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO ||
+			    ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+
+		if (ssdtso_available) {
+			ret = prctl(PR_SET_MEMORY_CONSISTENCY_MODEL,
+				    PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+			ASSERT_EQ(ret, 0);
+			ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+			ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_TSO);
+		} else {
+			ksft_test_result_skip("Ssdtso not available\n");
+		}
+
+		ret = prctl(PR_SET_MEMORY_CONSISTENCY_MODEL,
+			    PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO);
+		ASSERT_EQ(ret, 0);
+		ret = prctl(PR_GET_MEMORY_CONSISTENCY_MODEL);
+		ASSERT_TRUE(ret == PR_MEMORY_CONSISTENCY_MODEL_RISCV_WMO);
+	} else {
+		ASSERT_EQ(ssdtso_available, false);
+		ksft_test_result_skip("Ssdtso not configured\n");
+	}
+}
+
+TEST_HARNESS_MAIN
-- 
2.41.0


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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> From: Christoph Müllner <christoph.muellner@vrull.eu>
> 
> The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> CSR to switch the memory consistency model at run-time from RVWMO to TSO
> (and back). The active consistency model can therefore be switched on a
> per-hart base and managed by the kernel on a per-process/thread base.

You guys, computers are hartless, nobody told ya?

> This patch implements basic Ssdtso support and adds a prctl API on top
> so that user-space processes can switch to a stronger memory consistency
> model (than the kernel was written for) at run-time.
> 
> I am not sure if other architectures support switching the memory
> consistency model at run-time, but designing the prctl API in an
> arch-independent way allows reusing it in the future.

IIRC some Sparc chips could do this, but I don't think anybody ever
exposed this to userspace (or used it much).

IA64 had planned to do this, except they messed it up and did it the
wrong way around (strong first and then relax it later), which lead to
the discovery that all existing software broke (d'uh).

I think ARM64 approached this problem by adding the
load-acquire/store-release instructions and for TSO based code,
translate into those (eg. x86 -> arm64 transpilers).

IIRC Risc-V actually has such instructions as well, so *why* are you
doing this?!?!

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> From: Christoph Müllner <christoph.muellner@vrull.eu>
> 
> The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> CSR to switch the memory consistency model at run-time from RVWMO to TSO
> (and back). The active consistency model can therefore be switched on a
> per-hart base and managed by the kernel on a per-process/thread base.

You guys, computers are hartless, nobody told ya?

> This patch implements basic Ssdtso support and adds a prctl API on top
> so that user-space processes can switch to a stronger memory consistency
> model (than the kernel was written for) at run-time.
> 
> I am not sure if other architectures support switching the memory
> consistency model at run-time, but designing the prctl API in an
> arch-independent way allows reusing it in the future.

IIRC some Sparc chips could do this, but I don't think anybody ever
exposed this to userspace (or used it much).

IA64 had planned to do this, except they messed it up and did it the
wrong way around (strong first and then relax it later), which lead to
the discovery that all existing software broke (d'uh).

I think ARM64 approached this problem by adding the
load-acquire/store-release instructions and for TSO based code,
translate into those (eg. x86 -> arm64 transpilers).

IIRC Risc-V actually has such instructions as well, so *why* are you
doing this?!?!

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Christoph Müllner]

On Fri, Nov 24, 2023 at 11:15 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> >
> > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > (and back). The active consistency model can therefore be switched on a
> > per-hart base and managed by the kernel on a per-process/thread base.
>
> You guys, computers are hartless, nobody told ya?

That's why they came up with RISC-V, the ISA with hart!

> > This patch implements basic Ssdtso support and adds a prctl API on top
> > so that user-space processes can switch to a stronger memory consistency
> > model (than the kernel was written for) at run-time.
> >
> > I am not sure if other architectures support switching the memory
> > consistency model at run-time, but designing the prctl API in an
> > arch-independent way allows reusing it in the future.
>
> IIRC some Sparc chips could do this, but I don't think anybody ever
> exposed this to userspace (or used it much).
>
> IA64 had planned to do this, except they messed it up and did it the
> wrong way around (strong first and then relax it later), which lead to
> the discovery that all existing software broke (d'uh).
>
> I think ARM64 approached this problem by adding the
> load-acquire/store-release instructions and for TSO based code,
> translate into those (eg. x86 -> arm64 transpilers).
>
> IIRC Risc-V actually has such instructions as well, so *why* are you
> doing this?!?!

Not needing a transpiler is already a benefit.
And the DTSO approach also covers the cases where transpilers can't be used
(e.g. binary-only executables or libraries).

We are also working on extending ld.so such, that it switches to DTSO
(if available) in case the user wants to start an executable that was
compiled for Ztso or loads a library that was compiled for Ztso.
This would utilize the API that is introduced in this patchset.

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Christoph Müllner]

On Fri, Nov 24, 2023 at 11:15 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> >
> > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > (and back). The active consistency model can therefore be switched on a
> > per-hart base and managed by the kernel on a per-process/thread base.
>
> You guys, computers are hartless, nobody told ya?

That's why they came up with RISC-V, the ISA with hart!

> > This patch implements basic Ssdtso support and adds a prctl API on top
> > so that user-space processes can switch to a stronger memory consistency
> > model (than the kernel was written for) at run-time.
> >
> > I am not sure if other architectures support switching the memory
> > consistency model at run-time, but designing the prctl API in an
> > arch-independent way allows reusing it in the future.
>
> IIRC some Sparc chips could do this, but I don't think anybody ever
> exposed this to userspace (or used it much).
>
> IA64 had planned to do this, except they messed it up and did it the
> wrong way around (strong first and then relax it later), which lead to
> the discovery that all existing software broke (d'uh).
>
> I think ARM64 approached this problem by adding the
> load-acquire/store-release instructions and for TSO based code,
> translate into those (eg. x86 -> arm64 transpilers).
>
> IIRC Risc-V actually has such instructions as well, so *why* are you
> doing this?!?!

Not needing a transpiler is already a benefit.
And the DTSO approach also covers the cases where transpilers can't be used
(e.g. binary-only executables or libraries).

We are also working on extending ld.so such, that it switches to DTSO
(if available) in case the user wants to start an executable that was
compiled for Ztso or loads a library that was compiled for Ztso.
This would utilize the API that is introduced in this patchset.

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 11:53:06AM +0100, Christoph Müllner wrote:

> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).
> >
> > IIRC Risc-V actually has such instructions as well, so *why* are you
> > doing this?!?!
> 
> Not needing a transpiler is already a benefit.

This don't make sense, native risc-v stuff knows about the weak stuff,
its your natve model. The only reason you would ever need this dynamic
TSO stuff, is if you're going to run code that's written for some other
platform (notably x86).

> And the DTSO approach also covers the cases where transpilers can't be used
> (e.g. binary-only executables or libraries).

Uhh.. have you looked at the x86-on-arm64 things? That's all binary to
binary magic.

> We are also working on extending ld.so such, that it switches to DTSO
> (if available) in case the user wants to start an executable that was
> compiled for Ztso or loads a library that was compiled for Ztso.
> This would utilize the API that is introduced in this patchset.

I mean, sure, but *why* would you do this to your users? Who would want
to build a native risc-v tso binary?

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 11:53:06AM +0100, Christoph Müllner wrote:

> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).
> >
> > IIRC Risc-V actually has such instructions as well, so *why* are you
> > doing this?!?!
> 
> Not needing a transpiler is already a benefit.

This don't make sense, native risc-v stuff knows about the weak stuff,
its your natve model. The only reason you would ever need this dynamic
TSO stuff, is if you're going to run code that's written for some other
platform (notably x86).

> And the DTSO approach also covers the cases where transpilers can't be used
> (e.g. binary-only executables or libraries).

Uhh.. have you looked at the x86-on-arm64 things? That's all binary to
binary magic.

> We are also working on extending ld.so such, that it switches to DTSO
> (if available) in case the user wants to start an executable that was
> compiled for Ztso or loads a library that was compiled for Ztso.
> This would utilize the API that is introduced in this patchset.

I mean, sure, but *why* would you do this to your users? Who would want
to build a native risc-v tso binary?

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:

> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).
> 
> 
> Although those instructions have a bit more ordering constraints.
> 
> I have heard rumors that the apple chips also have a register that can be
> set at runtime.

Oh, I thought they made do with the load-acquire/store-release thingies.
But to be fair, I haven't been paying *that* much attention to the apple
stuff.

I did read about how they fudged some of the x86 flags thing.

> And there are some IBM machines that have a setting, but not sure how it is
> controlled.

Cute, I'm assuming this is the Power series (s390 already being TSO)? I
wasn't aware they had this.

> > IIRC Risc-V actually has such instructions as well, so *why* are you
> > doing this?!?!
> 
> 
> Unfortunately, at least last time I checked RISC-V still hadn't gotten such
> instructions.
> What they have is the *semantics* of the instructions, but no actual opcodes
> to encode them.

Well, that sucks..

> I argued for them in the RISC-V memory group, but it was considered to be
> outside the scope of that group.
> 
> Transpiling with sufficient DMB ISH to get the desired ordering is really
> bad for performance.

Ha!, quite dreadful I would imagine.

> That is not to say that linux should support this. Perhaps linux should
> pressure RISC-V into supporting implicit barriers instead.

I'm not sure I count for much in this regard, but yeah, that sounds like
a plan :-)

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:

> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).
> 
> 
> Although those instructions have a bit more ordering constraints.
> 
> I have heard rumors that the apple chips also have a register that can be
> set at runtime.

Oh, I thought they made do with the load-acquire/store-release thingies.
But to be fair, I haven't been paying *that* much attention to the apple
stuff.

I did read about how they fudged some of the x86 flags thing.

> And there are some IBM machines that have a setting, but not sure how it is
> controlled.

Cute, I'm assuming this is the Power series (s390 already being TSO)? I
wasn't aware they had this.

> > IIRC Risc-V actually has such instructions as well, so *why* are you
> > doing this?!?!
> 
> 
> Unfortunately, at least last time I checked RISC-V still hadn't gotten such
> instructions.
> What they have is the *semantics* of the instructions, but no actual opcodes
> to encode them.

Well, that sucks..

> I argued for them in the RISC-V memory group, but it was considered to be
> outside the scope of that group.
> 
> Transpiling with sufficient DMB ISH to get the desired ordering is really
> bad for performance.

Ha!, quite dreadful I would imagine.

> That is not to say that linux should support this. Perhaps linux should
> pressure RISC-V into supporting implicit barriers instead.

I'm not sure I count for much in this regard, but yeah, that sounds like
a plan :-)

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Michael Ellerman]

Peter Zijlstra <peterz@infradead.org> writes:
> On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
>
>> > I think ARM64 approached this problem by adding the
>> > load-acquire/store-release instructions and for TSO based code,
>> > translate into those (eg. x86 -> arm64 transpilers).
>> 
>> 
>> Although those instructions have a bit more ordering constraints.
>> 
>> I have heard rumors that the apple chips also have a register that can be
>> set at runtime.
>
> Oh, I thought they made do with the load-acquire/store-release thingies.
> But to be fair, I haven't been paying *that* much attention to the apple
> stuff.
>
> I did read about how they fudged some of the x86 flags thing.
>
>> And there are some IBM machines that have a setting, but not sure how it is
>> controlled.
>
> Cute, I'm assuming this is the Power series (s390 already being TSO)? I
> wasn't aware they had this.

Are you referring to Strong Access Ordering? That is a per-page
attribute, not a CPU mode, and was removed in ISA v3.1 anyway.

cheers

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Michael Ellerman]

Peter Zijlstra <peterz@infradead.org> writes:
> On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
>
>> > I think ARM64 approached this problem by adding the
>> > load-acquire/store-release instructions and for TSO based code,
>> > translate into those (eg. x86 -> arm64 transpilers).
>> 
>> 
>> Although those instructions have a bit more ordering constraints.
>> 
>> I have heard rumors that the apple chips also have a register that can be
>> set at runtime.
>
> Oh, I thought they made do with the load-acquire/store-release thingies.
> But to be fair, I haven't been paying *that* much attention to the apple
> stuff.
>
> I did read about how they fudged some of the x86 flags thing.
>
>> And there are some IBM machines that have a setting, but not sure how it is
>> controlled.
>
> Cute, I'm assuming this is the Power series (s390 already being TSO)? I
> wasn't aware they had this.

Are you referring to Strong Access Ordering? That is a per-page
attribute, not a CPU mode, and was removed in ISA v3.1 anyway.

cheers

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

Re: [RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model

[kernel test robot]

Hi Christoph,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on shuah-kselftest/next]
[also build test ERROR on shuah-kselftest/fixes linus/master v6.7-rc2 next-20231124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Christoph-Muellner/RISC-V-Add-basic-Ssdtso-support/20231124-153009
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
patch link:    https://lore.kernel.org/r/20231124072142.2786653-4-christoph.muellner%40vrull.eu
patch subject: [RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model
config: x86_64-buildonly-randconfig-002-20231124 (https://download.01.org/0day-ci/archive/20231124/202311241858.ujajxgyN-lkp@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231124/202311241858.ujajxgyN-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311241858.ujajxgyN-lkp@intel.com/

All errors (new ones prefixed by >>):

>> kernel/sys.c:2749:39: error: called object type 'int' is not a function or function pointer
                   error = SET_MEMORY_CONSISTENCY_MODEL(arg2);
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
   kernel/sys.c:2752:39: error: called object type 'int' is not a function or function pointer
                   error = GET_MEMORY_CONSISTENCY_MODEL();
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
   2 errors generated.


vim +/int +2749 kernel/sys.c

  2432	
  2433	SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
  2434			unsigned long, arg4, unsigned long, arg5)
  2435	{
  2436		struct task_struct *me = current;
  2437		unsigned char comm[sizeof(me->comm)];
  2438		long error;
  2439	
  2440		error = security_task_prctl(option, arg2, arg3, arg4, arg5);
  2441		if (error != -ENOSYS)
  2442			return error;
  2443	
  2444		error = 0;
  2445		switch (option) {
  2446		case PR_SET_PDEATHSIG:
  2447			if (!valid_signal(arg2)) {
  2448				error = -EINVAL;
  2449				break;
  2450			}
  2451			me->pdeath_signal = arg2;
  2452			break;
  2453		case PR_GET_PDEATHSIG:
  2454			error = put_user(me->pdeath_signal, (int __user *)arg2);
  2455			break;
  2456		case PR_GET_DUMPABLE:
  2457			error = get_dumpable(me->mm);
  2458			break;
  2459		case PR_SET_DUMPABLE:
  2460			if (arg2 != SUID_DUMP_DISABLE && arg2 != SUID_DUMP_USER) {
  2461				error = -EINVAL;
  2462				break;
  2463			}
  2464			set_dumpable(me->mm, arg2);
  2465			break;
  2466	
  2467		case PR_SET_UNALIGN:
  2468			error = SET_UNALIGN_CTL(me, arg2);
  2469			break;
  2470		case PR_GET_UNALIGN:
  2471			error = GET_UNALIGN_CTL(me, arg2);
  2472			break;
  2473		case PR_SET_FPEMU:
  2474			error = SET_FPEMU_CTL(me, arg2);
  2475			break;
  2476		case PR_GET_FPEMU:
  2477			error = GET_FPEMU_CTL(me, arg2);
  2478			break;
  2479		case PR_SET_FPEXC:
  2480			error = SET_FPEXC_CTL(me, arg2);
  2481			break;
  2482		case PR_GET_FPEXC:
  2483			error = GET_FPEXC_CTL(me, arg2);
  2484			break;
  2485		case PR_GET_TIMING:
  2486			error = PR_TIMING_STATISTICAL;
  2487			break;
  2488		case PR_SET_TIMING:
  2489			if (arg2 != PR_TIMING_STATISTICAL)
  2490				error = -EINVAL;
  2491			break;
  2492		case PR_SET_NAME:
  2493			comm[sizeof(me->comm) - 1] = 0;
  2494			if (strncpy_from_user(comm, (char __user *)arg2,
  2495					      sizeof(me->comm) - 1) < 0)
  2496				return -EFAULT;
  2497			set_task_comm(me, comm);
  2498			proc_comm_connector(me);
  2499			break;
  2500		case PR_GET_NAME:
  2501			get_task_comm(comm, me);
  2502			if (copy_to_user((char __user *)arg2, comm, sizeof(comm)))
  2503				return -EFAULT;
  2504			break;
  2505		case PR_GET_ENDIAN:
  2506			error = GET_ENDIAN(me, arg2);
  2507			break;
  2508		case PR_SET_ENDIAN:
  2509			error = SET_ENDIAN(me, arg2);
  2510			break;
  2511		case PR_GET_SECCOMP:
  2512			error = prctl_get_seccomp();
  2513			break;
  2514		case PR_SET_SECCOMP:
  2515			error = prctl_set_seccomp(arg2, (char __user *)arg3);
  2516			break;
  2517		case PR_GET_TSC:
  2518			error = GET_TSC_CTL(arg2);
  2519			break;
  2520		case PR_SET_TSC:
  2521			error = SET_TSC_CTL(arg2);
  2522			break;
  2523		case PR_TASK_PERF_EVENTS_DISABLE:
  2524			error = perf_event_task_disable();
  2525			break;
  2526		case PR_TASK_PERF_EVENTS_ENABLE:
  2527			error = perf_event_task_enable();
  2528			break;
  2529		case PR_GET_TIMERSLACK:
  2530			if (current->timer_slack_ns > ULONG_MAX)
  2531				error = ULONG_MAX;
  2532			else
  2533				error = current->timer_slack_ns;
  2534			break;
  2535		case PR_SET_TIMERSLACK:
  2536			if (arg2 <= 0)
  2537				current->timer_slack_ns =
  2538						current->default_timer_slack_ns;
  2539			else
  2540				current->timer_slack_ns = arg2;
  2541			break;
  2542		case PR_MCE_KILL:
  2543			if (arg4 | arg5)
  2544				return -EINVAL;
  2545			switch (arg2) {
  2546			case PR_MCE_KILL_CLEAR:
  2547				if (arg3 != 0)
  2548					return -EINVAL;
  2549				current->flags &= ~PF_MCE_PROCESS;
  2550				break;
  2551			case PR_MCE_KILL_SET:
  2552				current->flags |= PF_MCE_PROCESS;
  2553				if (arg3 == PR_MCE_KILL_EARLY)
  2554					current->flags |= PF_MCE_EARLY;
  2555				else if (arg3 == PR_MCE_KILL_LATE)
  2556					current->flags &= ~PF_MCE_EARLY;
  2557				else if (arg3 == PR_MCE_KILL_DEFAULT)
  2558					current->flags &=
  2559							~(PF_MCE_EARLY|PF_MCE_PROCESS);
  2560				else
  2561					return -EINVAL;
  2562				break;
  2563			default:
  2564				return -EINVAL;
  2565			}
  2566			break;
  2567		case PR_MCE_KILL_GET:
  2568			if (arg2 | arg3 | arg4 | arg5)
  2569				return -EINVAL;
  2570			if (current->flags & PF_MCE_PROCESS)
  2571				error = (current->flags & PF_MCE_EARLY) ?
  2572					PR_MCE_KILL_EARLY : PR_MCE_KILL_LATE;
  2573			else
  2574				error = PR_MCE_KILL_DEFAULT;
  2575			break;
  2576		case PR_SET_MM:
  2577			error = prctl_set_mm(arg2, arg3, arg4, arg5);
  2578			break;
  2579		case PR_GET_TID_ADDRESS:
  2580			error = prctl_get_tid_address(me, (int __user * __user *)arg2);
  2581			break;
  2582		case PR_SET_CHILD_SUBREAPER:
  2583			me->signal->is_child_subreaper = !!arg2;
  2584			if (!arg2)
  2585				break;
  2586	
  2587			walk_process_tree(me, propagate_has_child_subreaper, NULL);
  2588			break;
  2589		case PR_GET_CHILD_SUBREAPER:
  2590			error = put_user(me->signal->is_child_subreaper,
  2591					 (int __user *)arg2);
  2592			break;
  2593		case PR_SET_NO_NEW_PRIVS:
  2594			if (arg2 != 1 || arg3 || arg4 || arg5)
  2595				return -EINVAL;
  2596	
  2597			task_set_no_new_privs(current);
  2598			break;
  2599		case PR_GET_NO_NEW_PRIVS:
  2600			if (arg2 || arg3 || arg4 || arg5)
  2601				return -EINVAL;
  2602			return task_no_new_privs(current) ? 1 : 0;
  2603		case PR_GET_THP_DISABLE:
  2604			if (arg2 || arg3 || arg4 || arg5)
  2605				return -EINVAL;
  2606			error = !!test_bit(MMF_DISABLE_THP, &me->mm->flags);
  2607			break;
  2608		case PR_SET_THP_DISABLE:
  2609			if (arg3 || arg4 || arg5)
  2610				return -EINVAL;
  2611			if (mmap_write_lock_killable(me->mm))
  2612				return -EINTR;
  2613			if (arg2)
  2614				set_bit(MMF_DISABLE_THP, &me->mm->flags);
  2615			else
  2616				clear_bit(MMF_DISABLE_THP, &me->mm->flags);
  2617			mmap_write_unlock(me->mm);
  2618			break;
  2619		case PR_MPX_ENABLE_MANAGEMENT:
  2620		case PR_MPX_DISABLE_MANAGEMENT:
  2621			/* No longer implemented: */
  2622			return -EINVAL;
  2623		case PR_SET_FP_MODE:
  2624			error = SET_FP_MODE(me, arg2);
  2625			break;
  2626		case PR_GET_FP_MODE:
  2627			error = GET_FP_MODE(me);
  2628			break;
  2629		case PR_SVE_SET_VL:
  2630			error = SVE_SET_VL(arg2);
  2631			break;
  2632		case PR_SVE_GET_VL:
  2633			error = SVE_GET_VL();
  2634			break;
  2635		case PR_SME_SET_VL:
  2636			error = SME_SET_VL(arg2);
  2637			break;
  2638		case PR_SME_GET_VL:
  2639			error = SME_GET_VL();
  2640			break;
  2641		case PR_GET_SPECULATION_CTRL:
  2642			if (arg3 || arg4 || arg5)
  2643				return -EINVAL;
  2644			error = arch_prctl_spec_ctrl_get(me, arg2);
  2645			break;
  2646		case PR_SET_SPECULATION_CTRL:
  2647			if (arg4 || arg5)
  2648				return -EINVAL;
  2649			error = arch_prctl_spec_ctrl_set(me, arg2, arg3);
  2650			break;
  2651		case PR_PAC_RESET_KEYS:
  2652			if (arg3 || arg4 || arg5)
  2653				return -EINVAL;
  2654			error = PAC_RESET_KEYS(me, arg2);
  2655			break;
  2656		case PR_PAC_SET_ENABLED_KEYS:
  2657			if (arg4 || arg5)
  2658				return -EINVAL;
  2659			error = PAC_SET_ENABLED_KEYS(me, arg2, arg3);
  2660			break;
  2661		case PR_PAC_GET_ENABLED_KEYS:
  2662			if (arg2 || arg3 || arg4 || arg5)
  2663				return -EINVAL;
  2664			error = PAC_GET_ENABLED_KEYS(me);
  2665			break;
  2666		case PR_SET_TAGGED_ADDR_CTRL:
  2667			if (arg3 || arg4 || arg5)
  2668				return -EINVAL;
  2669			error = SET_TAGGED_ADDR_CTRL(arg2);
  2670			break;
  2671		case PR_GET_TAGGED_ADDR_CTRL:
  2672			if (arg2 || arg3 || arg4 || arg5)
  2673				return -EINVAL;
  2674			error = GET_TAGGED_ADDR_CTRL();
  2675			break;
  2676		case PR_SET_IO_FLUSHER:
  2677			if (!capable(CAP_SYS_RESOURCE))
  2678				return -EPERM;
  2679	
  2680			if (arg3 || arg4 || arg5)
  2681				return -EINVAL;
  2682	
  2683			if (arg2 == 1)
  2684				current->flags |= PR_IO_FLUSHER;
  2685			else if (!arg2)
  2686				current->flags &= ~PR_IO_FLUSHER;
  2687			else
  2688				return -EINVAL;
  2689			break;
  2690		case PR_GET_IO_FLUSHER:
  2691			if (!capable(CAP_SYS_RESOURCE))
  2692				return -EPERM;
  2693	
  2694			if (arg2 || arg3 || arg4 || arg5)
  2695				return -EINVAL;
  2696	
  2697			error = (current->flags & PR_IO_FLUSHER) == PR_IO_FLUSHER;
  2698			break;
  2699		case PR_SET_SYSCALL_USER_DISPATCH:
  2700			error = set_syscall_user_dispatch(arg2, arg3, arg4,
  2701							  (char __user *) arg5);
  2702			break;
  2703	#ifdef CONFIG_SCHED_CORE
  2704		case PR_SCHED_CORE:
  2705			error = sched_core_share_pid(arg2, arg3, arg4, arg5);
  2706			break;
  2707	#endif
  2708		case PR_SET_MDWE:
  2709			error = prctl_set_mdwe(arg2, arg3, arg4, arg5);
  2710			break;
  2711		case PR_GET_MDWE:
  2712			error = prctl_get_mdwe(arg2, arg3, arg4, arg5);
  2713			break;
  2714		case PR_SET_VMA:
  2715			error = prctl_set_vma(arg2, arg3, arg4, arg5);
  2716			break;
  2717		case PR_GET_AUXV:
  2718			if (arg4 || arg5)
  2719				return -EINVAL;
  2720			error = prctl_get_auxv((void __user *)arg2, arg3);
  2721			break;
  2722	#ifdef CONFIG_KSM
  2723		case PR_SET_MEMORY_MERGE:
  2724			if (arg3 || arg4 || arg5)
  2725				return -EINVAL;
  2726			if (mmap_write_lock_killable(me->mm))
  2727				return -EINTR;
  2728	
  2729			if (arg2)
  2730				error = ksm_enable_merge_any(me->mm);
  2731			else
  2732				error = ksm_disable_merge_any(me->mm);
  2733			mmap_write_unlock(me->mm);
  2734			break;
  2735		case PR_GET_MEMORY_MERGE:
  2736			if (arg2 || arg3 || arg4 || arg5)
  2737				return -EINVAL;
  2738	
  2739			error = !!test_bit(MMF_VM_MERGE_ANY, &me->mm->flags);
  2740			break;
  2741	#endif
  2742		case PR_RISCV_V_SET_CONTROL:
  2743			error = RISCV_V_SET_CONTROL(arg2);
  2744			break;
  2745		case PR_RISCV_V_GET_CONTROL:
  2746			error = RISCV_V_GET_CONTROL();
  2747			break;
  2748		case PR_SET_MEMORY_CONSISTENCY_MODEL:
> 2749			error = SET_MEMORY_CONSISTENCY_MODEL(arg2);
  2750			break;
  2751		case PR_GET_MEMORY_CONSISTENCY_MODEL:
  2752			error = GET_MEMORY_CONSISTENCY_MODEL();
  2753			break;
  2754		default:
  2755			error = -EINVAL;
  2756			break;
  2757		}
  2758		return error;
  2759	}
  2760	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model

[kernel test robot]

Hi Christoph,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on shuah-kselftest/next]
[also build test ERROR on shuah-kselftest/fixes linus/master v6.7-rc2 next-20231124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Christoph-Muellner/RISC-V-Add-basic-Ssdtso-support/20231124-153009
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
patch link:    https://lore.kernel.org/r/20231124072142.2786653-4-christoph.muellner%40vrull.eu
patch subject: [RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model
config: x86_64-randconfig-001-20231124 (https://download.01.org/0day-ci/archive/20231124/202311241915.1PboZbFO-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231124/202311241915.1PboZbFO-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311241915.1PboZbFO-lkp@intel.com/

All errors (new ones prefixed by >>):

   kernel/sys.c: In function '__do_sys_prctl':
>> kernel/sys.c:150:41: error: called object is not a function or function pointer
     150 | # define SET_MEMORY_CONSISTENCY_MODEL   (-EINVAL)
         |                                         ^
   kernel/sys.c:2749:25: note: in expansion of macro 'SET_MEMORY_CONSISTENCY_MODEL'
    2749 |                 error = SET_MEMORY_CONSISTENCY_MODEL(arg2);
         |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
   kernel/sys.c:153:41: error: called object is not a function or function pointer
     153 | # define GET_MEMORY_CONSISTENCY_MODEL   (-EINVAL)
         |                                         ^
   kernel/sys.c:2752:25: note: in expansion of macro 'GET_MEMORY_CONSISTENCY_MODEL'
    2752 |                 error = GET_MEMORY_CONSISTENCY_MODEL();
         |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~


vim +150 kernel/sys.c

    79	
    80	#ifndef SET_UNALIGN_CTL
    81	# define SET_UNALIGN_CTL(a, b)	(-EINVAL)
    82	#endif
    83	#ifndef GET_UNALIGN_CTL
    84	# define GET_UNALIGN_CTL(a, b)	(-EINVAL)
    85	#endif
    86	#ifndef SET_FPEMU_CTL
    87	# define SET_FPEMU_CTL(a, b)	(-EINVAL)
    88	#endif
    89	#ifndef GET_FPEMU_CTL
    90	# define GET_FPEMU_CTL(a, b)	(-EINVAL)
    91	#endif
    92	#ifndef SET_FPEXC_CTL
    93	# define SET_FPEXC_CTL(a, b)	(-EINVAL)
    94	#endif
    95	#ifndef GET_FPEXC_CTL
    96	# define GET_FPEXC_CTL(a, b)	(-EINVAL)
    97	#endif
    98	#ifndef GET_ENDIAN
    99	# define GET_ENDIAN(a, b)	(-EINVAL)
   100	#endif
   101	#ifndef SET_ENDIAN
   102	# define SET_ENDIAN(a, b)	(-EINVAL)
   103	#endif
   104	#ifndef GET_TSC_CTL
   105	# define GET_TSC_CTL(a)		(-EINVAL)
   106	#endif
   107	#ifndef SET_TSC_CTL
   108	# define SET_TSC_CTL(a)		(-EINVAL)
   109	#endif
   110	#ifndef GET_FP_MODE
   111	# define GET_FP_MODE(a)		(-EINVAL)
   112	#endif
   113	#ifndef SET_FP_MODE
   114	# define SET_FP_MODE(a,b)	(-EINVAL)
   115	#endif
   116	#ifndef SVE_SET_VL
   117	# define SVE_SET_VL(a)		(-EINVAL)
   118	#endif
   119	#ifndef SVE_GET_VL
   120	# define SVE_GET_VL()		(-EINVAL)
   121	#endif
   122	#ifndef SME_SET_VL
   123	# define SME_SET_VL(a)		(-EINVAL)
   124	#endif
   125	#ifndef SME_GET_VL
   126	# define SME_GET_VL()		(-EINVAL)
   127	#endif
   128	#ifndef PAC_RESET_KEYS
   129	# define PAC_RESET_KEYS(a, b)	(-EINVAL)
   130	#endif
   131	#ifndef PAC_SET_ENABLED_KEYS
   132	# define PAC_SET_ENABLED_KEYS(a, b, c)	(-EINVAL)
   133	#endif
   134	#ifndef PAC_GET_ENABLED_KEYS
   135	# define PAC_GET_ENABLED_KEYS(a)	(-EINVAL)
   136	#endif
   137	#ifndef SET_TAGGED_ADDR_CTRL
   138	# define SET_TAGGED_ADDR_CTRL(a)	(-EINVAL)
   139	#endif
   140	#ifndef GET_TAGGED_ADDR_CTRL
   141	# define GET_TAGGED_ADDR_CTRL()		(-EINVAL)
   142	#endif
   143	#ifndef RISCV_V_SET_CONTROL
   144	# define RISCV_V_SET_CONTROL(a)		(-EINVAL)
   145	#endif
   146	#ifndef RISCV_V_GET_CONTROL
   147	# define RISCV_V_GET_CONTROL()		(-EINVAL)
   148	#endif
   149	#ifndef SET_MEMORY_CONSISTENCY_MODEL
 > 150	# define SET_MEMORY_CONSISTENCY_MODEL	(-EINVAL)
   151	#endif
   152	#ifndef GET_MEMORY_CONSISTENCY_MODEL
   153	# define GET_MEMORY_CONSISTENCY_MODEL	(-EINVAL)
   154	#endif
   155	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model

[kernel test robot]

Hi Christoph,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build warnings:

[auto build test WARNING on shuah-kselftest/next]
[also build test WARNING on shuah-kselftest/fixes linus/master v6.7-rc2 next-20231124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Christoph-Muellner/RISC-V-Add-basic-Ssdtso-support/20231124-153009
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
patch link:    https://lore.kernel.org/r/20231124072142.2786653-4-christoph.muellner%40vrull.eu
patch subject: [RFC PATCH 3/5] uapi: prctl: Add new prctl call to set/get the memory consistency model
reproduce: (https://download.01.org/0day-ci/archive/20231124/202311242003.esZBgqBn-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311242003.esZBgqBn-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> Documentation/mm/dynamic-memory-consistency-model.rst: WARNING: document isn't included in any toctree

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Guo Ren]

On Fri, Nov 24, 2023 at 11:15:19AM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> > 
> > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > (and back). The active consistency model can therefore be switched on a
> > per-hart base and managed by the kernel on a per-process/thread base.
> 
> You guys, computers are hartless, nobody told ya?
> 
> > This patch implements basic Ssdtso support and adds a prctl API on top
> > so that user-space processes can switch to a stronger memory consistency
> > model (than the kernel was written for) at run-time.
> > 
> > I am not sure if other architectures support switching the memory
> > consistency model at run-time, but designing the prctl API in an
> > arch-independent way allows reusing it in the future.
> 
> IIRC some Sparc chips could do this, but I don't think anybody ever
> exposed this to userspace (or used it much).
> 
> IA64 had planned to do this, except they messed it up and did it the
> wrong way around (strong first and then relax it later), which lead to
> the discovery that all existing software broke (d'uh).
> 
> I think ARM64 approached this problem by adding the
> load-acquire/store-release instructions and for TSO based code,
> translate into those (eg. x86 -> arm64 transpilers).
Keeping global TSO order is easier and faster than mixing
acquire/release and regular load/store. That means when ssdtso is
enabled, the transpiler's load-acquire/store-release becomes regular
load/store. Some micro-arch hardwares could speed up the performance.

Of course, you may say powerful machines could smooth out the difference
between ssdtso & load-acquire/store-release, but that's not real life.
Adding ssdtso is a flexible way to gain more choices on the cost of chip
design.

> 
> IIRC Risc-V actually has such instructions as well, so *why* are you
> doing this?!?!
> 

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Guo Ren]

On Fri, Nov 24, 2023 at 11:15:19AM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> > 
> > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > (and back). The active consistency model can therefore be switched on a
> > per-hart base and managed by the kernel on a per-process/thread base.
> 
> You guys, computers are hartless, nobody told ya?
> 
> > This patch implements basic Ssdtso support and adds a prctl API on top
> > so that user-space processes can switch to a stronger memory consistency
> > model (than the kernel was written for) at run-time.
> > 
> > I am not sure if other architectures support switching the memory
> > consistency model at run-time, but designing the prctl API in an
> > arch-independent way allows reusing it in the future.
> 
> IIRC some Sparc chips could do this, but I don't think anybody ever
> exposed this to userspace (or used it much).
> 
> IA64 had planned to do this, except they messed it up and did it the
> wrong way around (strong first and then relax it later), which lead to
> the discovery that all existing software broke (d'uh).
> 
> I think ARM64 approached this problem by adding the
> load-acquire/store-release instructions and for TSO based code,
> translate into those (eg. x86 -> arm64 transpilers).
Keeping global TSO order is easier and faster than mixing
acquire/release and regular load/store. That means when ssdtso is
enabled, the transpiler's load-acquire/store-release becomes regular
load/store. Some micro-arch hardwares could speed up the performance.

Of course, you may say powerful machines could smooth out the difference
between ssdtso & load-acquire/store-release, but that's not real life.
Adding ssdtso is a flexible way to gain more choices on the cost of chip
design.

> 
> IIRC Risc-V actually has such instructions as well, so *why* are you
> doing this?!?!
> 

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Guo Ren]

On Fri, Nov 24, 2023 at 12:54:30PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> 
> > > I think ARM64 approached this problem by adding the
> > > load-acquire/store-release instructions and for TSO based code,
> > > translate into those (eg. x86 -> arm64 transpilers).
> > 
> > 
> > Although those instructions have a bit more ordering constraints.
> > 
> > I have heard rumors that the apple chips also have a register that can be
> > set at runtime.
I could understand the rumor, smart design! Thx for sharing.

> 
> Oh, I thought they made do with the load-acquire/store-release thingies.
> But to be fair, I haven't been paying *that* much attention to the apple
> stuff.
> 
> I did read about how they fudged some of the x86 flags thing.
> 
> > And there are some IBM machines that have a setting, but not sure how it is
> > controlled.
> 
> Cute, I'm assuming this is the Power series (s390 already being TSO)? I
> wasn't aware they had this.
> 
> > > IIRC Risc-V actually has such instructions as well, so *why* are you
> > > doing this?!?!
> > 
> > 
> > Unfortunately, at least last time I checked RISC-V still hadn't gotten such
> > instructions.
> > What they have is the *semantics* of the instructions, but no actual opcodes
> > to encode them.
> 
> Well, that sucks..
> 
> > I argued for them in the RISC-V memory group, but it was considered to be
> > outside the scope of that group.
> > 
> > Transpiling with sufficient DMB ISH to get the desired ordering is really
> > bad for performance.
> 
> Ha!, quite dreadful I would imagine.
> 
> > That is not to say that linux should support this. Perhaps linux should
> > pressure RISC-V into supporting implicit barriers instead.
> 
> I'm not sure I count for much in this regard, but yeah, that sounds like
> a plan :-)
> 

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Guo Ren]

On Fri, Nov 24, 2023 at 12:54:30PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> 
> > > I think ARM64 approached this problem by adding the
> > > load-acquire/store-release instructions and for TSO based code,
> > > translate into those (eg. x86 -> arm64 transpilers).
> > 
> > 
> > Although those instructions have a bit more ordering constraints.
> > 
> > I have heard rumors that the apple chips also have a register that can be
> > set at runtime.
I could understand the rumor, smart design! Thx for sharing.

> 
> Oh, I thought they made do with the load-acquire/store-release thingies.
> But to be fair, I haven't been paying *that* much attention to the apple
> stuff.
> 
> I did read about how they fudged some of the x86 flags thing.
> 
> > And there are some IBM machines that have a setting, but not sure how it is
> > controlled.
> 
> Cute, I'm assuming this is the Power series (s390 already being TSO)? I
> wasn't aware they had this.
> 
> > > IIRC Risc-V actually has such instructions as well, so *why* are you
> > > doing this?!?!
> > 
> > 
> > Unfortunately, at least last time I checked RISC-V still hadn't gotten such
> > instructions.
> > What they have is the *semantics* of the instructions, but no actual opcodes
> > to encode them.
> 
> Well, that sucks..
> 
> > I argued for them in the RISC-V memory group, but it was considered to be
> > outside the scope of that group.
> > 
> > Transpiling with sufficient DMB ISH to get the desired ordering is really
> > bad for performance.
> 
> Ha!, quite dreadful I would imagine.
> 
> > That is not to say that linux should support this. Perhaps linux should
> > pressure RISC-V into supporting implicit barriers instead.
> 
> I'm not sure I count for much in this regard, but yeah, that sounds like
> a plan :-)
> 

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

Hi,

On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> From: Christoph Müllner <christoph.muellner@vrull.eu>
> 
> The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> CSR to switch the memory consistency model at run-time from RVWMO to TSO
> (and back). The active consistency model can therefore be switched on a
> per-hart base and managed by the kernel on a per-process/thread base.
> 
> This patch implements basic Ssdtso support and adds a prctl API on top
> so that user-space processes can switch to a stronger memory consistency
> model (than the kernel was written for) at run-time.
> 
> I am not sure if other architectures support switching the memory
> consistency model at run-time, but designing the prctl API in an
> arch-independent way allows reusing it in the future.
> 
> The patchset also comes with a short documentation of the prctl API.
> 
> This series is based on the second draft of the Ssdtso specification
> which was published recently on an RVI list:
>   https://lists.riscv.org/g/tech-arch-review/message/183
> Note, that the Ssdtso specification is in development state
> (i.e., not frozen or even ratified) which is also the reason
> why I marked the series as RFC.
> 
> One aspect that is not covered in this patchset is virtualization.
> It is planned to add virtualization support in a later version.
> Hints/suggestions on how to implement this part are very much
> appreciated.
> 
> Christoph Müllner (5):

I know this is an RFC, but it could probably do with a bit more compile
testing, as:

>   RISC-V: Add basic Ssdtso support

This patch doesn't build for rv64 allmodconfig

>   RISC-V: Expose Ssdtso via hwprobe API

This one seems to build fine

>   uapi: prctl: Add new prctl call to set/get the memory consistency
>     model
>   RISC-V: Implement prctl call to set/get the memory consistency model
>   RISC-V: selftests: Add DTSO tests

These don't build for:
rv32 defconfig
rv64 allmodconfig
rv64 nommu

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Conor Dooley]

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

Hi,

On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> From: Christoph Müllner <christoph.muellner@vrull.eu>
> 
> The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> CSR to switch the memory consistency model at run-time from RVWMO to TSO
> (and back). The active consistency model can therefore be switched on a
> per-hart base and managed by the kernel on a per-process/thread base.
> 
> This patch implements basic Ssdtso support and adds a prctl API on top
> so that user-space processes can switch to a stronger memory consistency
> model (than the kernel was written for) at run-time.
> 
> I am not sure if other architectures support switching the memory
> consistency model at run-time, but designing the prctl API in an
> arch-independent way allows reusing it in the future.
> 
> The patchset also comes with a short documentation of the prctl API.
> 
> This series is based on the second draft of the Ssdtso specification
> which was published recently on an RVI list:
>   https://lists.riscv.org/g/tech-arch-review/message/183
> Note, that the Ssdtso specification is in development state
> (i.e., not frozen or even ratified) which is also the reason
> why I marked the series as RFC.
> 
> One aspect that is not covered in this patchset is virtualization.
> It is planned to add virtualization support in a later version.
> Hints/suggestions on how to implement this part are very much
> appreciated.
> 
> Christoph Müllner (5):

I know this is an RFC, but it could probably do with a bit more compile
testing, as:

>   RISC-V: Add basic Ssdtso support

This patch doesn't build for rv64 allmodconfig

>   RISC-V: Expose Ssdtso via hwprobe API

This one seems to build fine

>   uapi: prctl: Add new prctl call to set/get the memory consistency
>     model
>   RISC-V: Implement prctl call to set/get the memory consistency model
>   RISC-V: selftests: Add DTSO tests

These don't build for:
rv32 defconfig
rv64 allmodconfig
rv64 nommu

Cheers,
Conor.

[-- 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: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 09:51:53PM -0500, Guo Ren wrote:
> On Fri, Nov 24, 2023 at 11:15:19AM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > > From: Christoph Müllner <christoph.muellner@vrull.eu>
> > > 
> > > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > > (and back). The active consistency model can therefore be switched on a
> > > per-hart base and managed by the kernel on a per-process/thread base.
> > 
> > You guys, computers are hartless, nobody told ya?
> > 
> > > This patch implements basic Ssdtso support and adds a prctl API on top
> > > so that user-space processes can switch to a stronger memory consistency
> > > model (than the kernel was written for) at run-time.
> > > 
> > > I am not sure if other architectures support switching the memory
> > > consistency model at run-time, but designing the prctl API in an
> > > arch-independent way allows reusing it in the future.
> > 
> > IIRC some Sparc chips could do this, but I don't think anybody ever
> > exposed this to userspace (or used it much).
> > 
> > IA64 had planned to do this, except they messed it up and did it the
> > wrong way around (strong first and then relax it later), which lead to
> > the discovery that all existing software broke (d'uh).
> > 
> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).

> Keeping global TSO order is easier and faster than mixing
> acquire/release and regular load/store. That means when ssdtso is
> enabled, the transpiler's load-acquire/store-release becomes regular
> load/store. Some micro-arch hardwares could speed up the performance.

Why is it faster? Because the release+acquire thing becomes RcSC instead
of RcTSO? Surely that can be fixed with a weaker store-release variant
ot something?

The problem I have with all of this is that you need to context switch
this state and that you need to deal with exceptions, which must be
written for the weak model but then end up running in the tso model --
possibly slower than desired.

If OTOH you only have a single model, everything becomes so much
simpler. You just need to be able to express exactly what you want.

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Peter Zijlstra]

On Fri, Nov 24, 2023 at 09:51:53PM -0500, Guo Ren wrote:
> On Fri, Nov 24, 2023 at 11:15:19AM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > > From: Christoph Müllner <christoph.muellner@vrull.eu>
> > > 
> > > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > > (and back). The active consistency model can therefore be switched on a
> > > per-hart base and managed by the kernel on a per-process/thread base.
> > 
> > You guys, computers are hartless, nobody told ya?
> > 
> > > This patch implements basic Ssdtso support and adds a prctl API on top
> > > so that user-space processes can switch to a stronger memory consistency
> > > model (than the kernel was written for) at run-time.
> > > 
> > > I am not sure if other architectures support switching the memory
> > > consistency model at run-time, but designing the prctl API in an
> > > arch-independent way allows reusing it in the future.
> > 
> > IIRC some Sparc chips could do this, but I don't think anybody ever
> > exposed this to userspace (or used it much).
> > 
> > IA64 had planned to do this, except they messed it up and did it the
> > wrong way around (strong first and then relax it later), which lead to
> > the discovery that all existing software broke (d'uh).
> > 
> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).

> Keeping global TSO order is easier and faster than mixing
> acquire/release and regular load/store. That means when ssdtso is
> enabled, the transpiler's load-acquire/store-release becomes regular
> load/store. Some micro-arch hardwares could speed up the performance.

Why is it faster? Because the release+acquire thing becomes RcSC instead
of RcTSO? Surely that can be fixed with a weaker store-release variant
ot something?

The problem I have with all of this is that you need to context switch
this state and that you need to deal with exceptions, which must be
written for the weak model but then end up running in the tso model --
possibly slower than desired.

If OTOH you only have a single model, everything becomes so much
simpler. You just need to be able to express exactly what you want.



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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Mark Rutland]

On Fri, Nov 24, 2023 at 12:54:30PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> > > I think ARM64 approached this problem by adding the
> > > load-acquire/store-release instructions and for TSO based code,
> > > translate into those (eg. x86 -> arm64 transpilers).
> > 
> > Although those instructions have a bit more ordering constraints.
> > 
> > I have heard rumors that the apple chips also have a register that can be
> > set at runtime.
> 
> Oh, I thought they made do with the load-acquire/store-release thingies.
> But to be fair, I haven't been paying *that* much attention to the apple
> stuff.
> 
> I did read about how they fudged some of the x86 flags thing.

I don't know what others may have built specifically, but architecturally on
arm64 we expect people to express ordering requirements through instructions.
ARMv8.0 has load-acquire and store-release, ARMv8.3 added RCpc forms of
load-acquire as part of FEAT_LRCPC, and ARMv8.4 added a number of instructions
as part of FEAT_LRCPC2.

For a number of reasons we avoid IMPLEMENTATION DEFINED controls for things
like this.

Thanks
Mark.

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Mark Rutland]

On Fri, Nov 24, 2023 at 12:54:30PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> > > I think ARM64 approached this problem by adding the
> > > load-acquire/store-release instructions and for TSO based code,
> > > translate into those (eg. x86 -> arm64 transpilers).
> > 
> > Although those instructions have a bit more ordering constraints.
> > 
> > I have heard rumors that the apple chips also have a register that can be
> > set at runtime.
> 
> Oh, I thought they made do with the load-acquire/store-release thingies.
> But to be fair, I haven't been paying *that* much attention to the apple
> stuff.
> 
> I did read about how they fudged some of the x86 flags thing.

I don't know what others may have built specifically, but architecturally on
arm64 we expect people to express ordering requirements through instructions.
ARMv8.0 has load-acquire and store-release, ARMv8.3 added RCpc forms of
load-acquire as part of FEAT_LRCPC, and ARMv8.4 added a number of instructions
as part of FEAT_LRCPC2.

For a number of reasons we avoid IMPLEMENTATION DEFINED controls for things
like this.

Thanks
Mark.

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Christoph Müllner]

On Mon, Nov 27, 2023 at 11:37 AM Conor Dooley
<conor.dooley@microchip.com> wrote:
>
> Hi,
>
> On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> >
> > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > (and back). The active consistency model can therefore be switched on a
> > per-hart base and managed by the kernel on a per-process/thread base.
> >
> > This patch implements basic Ssdtso support and adds a prctl API on top
> > so that user-space processes can switch to a stronger memory consistency
> > model (than the kernel was written for) at run-time.
> >
> > I am not sure if other architectures support switching the memory
> > consistency model at run-time, but designing the prctl API in an
> > arch-independent way allows reusing it in the future.
> >
> > The patchset also comes with a short documentation of the prctl API.
> >
> > This series is based on the second draft of the Ssdtso specification
> > which was published recently on an RVI list:
> >   https://lists.riscv.org/g/tech-arch-review/message/183
> > Note, that the Ssdtso specification is in development state
> > (i.e., not frozen or even ratified) which is also the reason
> > why I marked the series as RFC.
> >
> > One aspect that is not covered in this patchset is virtualization.
> > It is planned to add virtualization support in a later version.
> > Hints/suggestions on how to implement this part are very much
> > appreciated.
> >
> > Christoph Müllner (5):
>
> I know this is an RFC, but it could probably do with a bit more compile
> testing, as:
>
> >   RISC-V: Add basic Ssdtso support
>
> This patch doesn't build for rv64 allmodconfig
>
> >   RISC-V: Expose Ssdtso via hwprobe API
>
> This one seems to build fine
>
> >   uapi: prctl: Add new prctl call to set/get the memory consistency
> >     model
> >   RISC-V: Implement prctl call to set/get the memory consistency model
> >   RISC-V: selftests: Add DTSO tests
>
> These don't build for:
> rv32 defconfig
> rv64 allmodconfig
> rv64 nommu

Thanks for reporting this. You are absolutely right.
In my defense, this patchset was compile-tested and got some limited
run-time testing in QEMU.
But after that, I wrote the documentation, which triggered a renaming
of several function/macro names,
and these changes did not see adequate testing. I am sorry for that.

I've already fixed the patches (addressing the issues you have
reported, plus other small issues).
To not distract the ongoing discussion, I will not send an updated
patchset right now.
In case you are interested, you can find the latest changes (rebased
on upstream/master) here:
  https://github.com/cmuellner/linux/tree/ssdtso
I've also extended my local compile-test script to include all
mentioned configs.

In case you want to play a bit with these changes, you can also have a
look at the QEMU
patchset, which also got support for the prctl (which is not part of
the published mailpatch):
  https://github.com/cmuellner/qemu/tree/ssdtso
With these changes, you can run the kernel self-test binary in
user-mode emulation.

BR
Christoph

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Christoph Müllner]

On Mon, Nov 27, 2023 at 11:37 AM Conor Dooley
<conor.dooley@microchip.com> wrote:
>
> Hi,
>
> On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> >
> > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > (and back). The active consistency model can therefore be switched on a
> > per-hart base and managed by the kernel on a per-process/thread base.
> >
> > This patch implements basic Ssdtso support and adds a prctl API on top
> > so that user-space processes can switch to a stronger memory consistency
> > model (than the kernel was written for) at run-time.
> >
> > I am not sure if other architectures support switching the memory
> > consistency model at run-time, but designing the prctl API in an
> > arch-independent way allows reusing it in the future.
> >
> > The patchset also comes with a short documentation of the prctl API.
> >
> > This series is based on the second draft of the Ssdtso specification
> > which was published recently on an RVI list:
> >   https://lists.riscv.org/g/tech-arch-review/message/183
> > Note, that the Ssdtso specification is in development state
> > (i.e., not frozen or even ratified) which is also the reason
> > why I marked the series as RFC.
> >
> > One aspect that is not covered in this patchset is virtualization.
> > It is planned to add virtualization support in a later version.
> > Hints/suggestions on how to implement this part are very much
> > appreciated.
> >
> > Christoph Müllner (5):
>
> I know this is an RFC, but it could probably do with a bit more compile
> testing, as:
>
> >   RISC-V: Add basic Ssdtso support
>
> This patch doesn't build for rv64 allmodconfig
>
> >   RISC-V: Expose Ssdtso via hwprobe API
>
> This one seems to build fine
>
> >   uapi: prctl: Add new prctl call to set/get the memory consistency
> >     model
> >   RISC-V: Implement prctl call to set/get the memory consistency model
> >   RISC-V: selftests: Add DTSO tests
>
> These don't build for:
> rv32 defconfig
> rv64 allmodconfig
> rv64 nommu

Thanks for reporting this. You are absolutely right.
In my defense, this patchset was compile-tested and got some limited
run-time testing in QEMU.
But after that, I wrote the documentation, which triggered a renaming
of several function/macro names,
and these changes did not see adequate testing. I am sorry for that.

I've already fixed the patches (addressing the issues you have
reported, plus other small issues).
To not distract the ongoing discussion, I will not send an updated
patchset right now.
In case you are interested, you can find the latest changes (rebased
on upstream/master) here:
  https://github.com/cmuellner/linux/tree/ssdtso
I've also extended my local compile-test script to include all
mentioned configs.

In case you want to play a bit with these changes, you can also have a
look at the QEMU
patchset, which also got support for the prctl (which is not part of
the published mailpatch):
  https://github.com/cmuellner/qemu/tree/ssdtso
With these changes, you can run the kernel self-test binary in
user-mode emulation.

BR
Christoph

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

Re: [RFC PATCH 2/5] RISC-V: Expose Ssdtso via hwprobe API

[Samuel Holland]

Hi Christoph,

On 2023-11-24 1:21 AM, Christoph Muellner wrote:
> From: Christoph Müllner <christoph.muellner@vrull.eu>
> 
> This patch adds Ssdtso to the list of extensions which
> are announced to user-space using te hwprobe API.
> 
> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
> ---
>  Documentation/arch/riscv/hwprobe.rst  | 3 +++
>  arch/riscv/include/uapi/asm/hwprobe.h | 1 +
>  arch/riscv/kernel/sys_riscv.c         | 1 +
>  3 files changed, 5 insertions(+)
> 
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index 7b2384de471f..8de3349e0ca2 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -80,6 +80,9 @@ The following keys are defined:
>    * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
>         ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
>  
> +  * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Ssdtso extension is supported, as

Should be RISCV_HWPROBE_EXT_SSDTSO.

Regards,
Samuel

> +       in version v1.0-draft2 of the corresponding extension.
> +
>  * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
>    information about the selected set of processors.
>  
> diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> index b659ffcfcdb4..ed450c64e6b2 100644
> --- a/arch/riscv/include/uapi/asm/hwprobe.h
> +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> @@ -30,6 +30,7 @@ struct riscv_hwprobe {
>  #define		RISCV_HWPROBE_EXT_ZBB		(1 << 4)
>  #define		RISCV_HWPROBE_EXT_ZBS		(1 << 5)
>  #define		RISCV_HWPROBE_EXT_ZICBOZ	(1 << 6)
> +#define		RISCV_HWPROBE_EXT_SSDTSO	(1 << 7)
>  #define RISCV_HWPROBE_KEY_CPUPERF_0	5
>  #define		RISCV_HWPROBE_MISALIGNED_UNKNOWN	(0 << 0)
>  #define		RISCV_HWPROBE_MISALIGNED_EMULATED	(1 << 0)
> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> index c712037dbe10..c654f43b9699 100644
> --- a/arch/riscv/kernel/sys_riscv.c
> +++ b/arch/riscv/kernel/sys_riscv.c
> @@ -162,6 +162,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
>  		EXT_KEY(ZBB);
>  		EXT_KEY(ZBS);
>  		EXT_KEY(ZICBOZ);
> +		EXT_KEY(SSDTSO);
>  #undef EXT_KEY
>  	}
>  

Re: [RFC PATCH 2/5] RISC-V: Expose Ssdtso via hwprobe API

[Samuel Holland]

Hi Christoph,

On 2023-11-24 1:21 AM, Christoph Muellner wrote:
> From: Christoph Müllner <christoph.muellner@vrull.eu>
> 
> This patch adds Ssdtso to the list of extensions which
> are announced to user-space using te hwprobe API.
> 
> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
> ---
>  Documentation/arch/riscv/hwprobe.rst  | 3 +++
>  arch/riscv/include/uapi/asm/hwprobe.h | 1 +
>  arch/riscv/kernel/sys_riscv.c         | 1 +
>  3 files changed, 5 insertions(+)
> 
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index 7b2384de471f..8de3349e0ca2 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -80,6 +80,9 @@ The following keys are defined:
>    * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
>         ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
>  
> +  * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Ssdtso extension is supported, as

Should be RISCV_HWPROBE_EXT_SSDTSO.

Regards,
Samuel

> +       in version v1.0-draft2 of the corresponding extension.
> +
>  * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
>    information about the selected set of processors.
>  
> diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> index b659ffcfcdb4..ed450c64e6b2 100644
> --- a/arch/riscv/include/uapi/asm/hwprobe.h
> +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> @@ -30,6 +30,7 @@ struct riscv_hwprobe {
>  #define		RISCV_HWPROBE_EXT_ZBB		(1 << 4)
>  #define		RISCV_HWPROBE_EXT_ZBS		(1 << 5)
>  #define		RISCV_HWPROBE_EXT_ZICBOZ	(1 << 6)
> +#define		RISCV_HWPROBE_EXT_SSDTSO	(1 << 7)
>  #define RISCV_HWPROBE_KEY_CPUPERF_0	5
>  #define		RISCV_HWPROBE_MISALIGNED_UNKNOWN	(0 << 0)
>  #define		RISCV_HWPROBE_MISALIGNED_EMULATED	(1 << 0)
> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> index c712037dbe10..c654f43b9699 100644
> --- a/arch/riscv/kernel/sys_riscv.c
> +++ b/arch/riscv/kernel/sys_riscv.c
> @@ -162,6 +162,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
>  		EXT_KEY(ZBB);
>  		EXT_KEY(ZBS);
>  		EXT_KEY(ZICBOZ);
> +		EXT_KEY(SSDTSO);
>  #undef EXT_KEY
>  	}
>  


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

Re: [RFC PATCH 2/5] RISC-V: Expose Ssdtso via hwprobe API

[Christoph Müllner]

On Mon, Nov 27, 2023 at 3:32 PM Samuel Holland
<samuel.holland@sifive.com> wrote:
>
> Hi Christoph,
>
> On 2023-11-24 1:21 AM, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> >
> > This patch adds Ssdtso to the list of extensions which
> > are announced to user-space using te hwprobe API.
> >
> > Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
> > ---
> >  Documentation/arch/riscv/hwprobe.rst  | 3 +++
> >  arch/riscv/include/uapi/asm/hwprobe.h | 1 +
> >  arch/riscv/kernel/sys_riscv.c         | 1 +
> >  3 files changed, 5 insertions(+)
> >
> > diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> > index 7b2384de471f..8de3349e0ca2 100644
> > --- a/Documentation/arch/riscv/hwprobe.rst
> > +++ b/Documentation/arch/riscv/hwprobe.rst
> > @@ -80,6 +80,9 @@ The following keys are defined:
> >    * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
> >         ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
> >
> > +  * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Ssdtso extension is supported, as
>
> Should be RISCV_HWPROBE_EXT_SSDTSO.

Thanks for reporting!
I've fixed this now as well in the github branch:
  https://github.com/cmuellner/linux/tree/ssdtso

BR
Christoph

>
> Regards,
> Samuel
>
> > +       in version v1.0-draft2 of the corresponding extension.
> > +
> >  * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
> >    information about the selected set of processors.
> >
> > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> > index b659ffcfcdb4..ed450c64e6b2 100644
> > --- a/arch/riscv/include/uapi/asm/hwprobe.h
> > +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> > @@ -30,6 +30,7 @@ struct riscv_hwprobe {
> >  #define              RISCV_HWPROBE_EXT_ZBB           (1 << 4)
> >  #define              RISCV_HWPROBE_EXT_ZBS           (1 << 5)
> >  #define              RISCV_HWPROBE_EXT_ZICBOZ        (1 << 6)
> > +#define              RISCV_HWPROBE_EXT_SSDTSO        (1 << 7)
> >  #define RISCV_HWPROBE_KEY_CPUPERF_0  5
> >  #define              RISCV_HWPROBE_MISALIGNED_UNKNOWN        (0 << 0)
> >  #define              RISCV_HWPROBE_MISALIGNED_EMULATED       (1 << 0)
> > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> > index c712037dbe10..c654f43b9699 100644
> > --- a/arch/riscv/kernel/sys_riscv.c
> > +++ b/arch/riscv/kernel/sys_riscv.c
> > @@ -162,6 +162,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> >               EXT_KEY(ZBB);
> >               EXT_KEY(ZBS);
> >               EXT_KEY(ZICBOZ);
> > +             EXT_KEY(SSDTSO);
> >  #undef EXT_KEY
> >       }
> >
>

Re: [RFC PATCH 2/5] RISC-V: Expose Ssdtso via hwprobe API

[Christoph Müllner]

On Mon, Nov 27, 2023 at 3:32 PM Samuel Holland
<samuel.holland@sifive.com> wrote:
>
> Hi Christoph,
>
> On 2023-11-24 1:21 AM, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> >
> > This patch adds Ssdtso to the list of extensions which
> > are announced to user-space using te hwprobe API.
> >
> > Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
> > ---
> >  Documentation/arch/riscv/hwprobe.rst  | 3 +++
> >  arch/riscv/include/uapi/asm/hwprobe.h | 1 +
> >  arch/riscv/kernel/sys_riscv.c         | 1 +
> >  3 files changed, 5 insertions(+)
> >
> > diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> > index 7b2384de471f..8de3349e0ca2 100644
> > --- a/Documentation/arch/riscv/hwprobe.rst
> > +++ b/Documentation/arch/riscv/hwprobe.rst
> > @@ -80,6 +80,9 @@ The following keys are defined:
> >    * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
> >         ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
> >
> > +  * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Ssdtso extension is supported, as
>
> Should be RISCV_HWPROBE_EXT_SSDTSO.

Thanks for reporting!
I've fixed this now as well in the github branch:
  https://github.com/cmuellner/linux/tree/ssdtso

BR
Christoph

>
> Regards,
> Samuel
>
> > +       in version v1.0-draft2 of the corresponding extension.
> > +
> >  * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
> >    information about the selected set of processors.
> >
> > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> > index b659ffcfcdb4..ed450c64e6b2 100644
> > --- a/arch/riscv/include/uapi/asm/hwprobe.h
> > +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> > @@ -30,6 +30,7 @@ struct riscv_hwprobe {
> >  #define              RISCV_HWPROBE_EXT_ZBB           (1 << 4)
> >  #define              RISCV_HWPROBE_EXT_ZBS           (1 << 5)
> >  #define              RISCV_HWPROBE_EXT_ZICBOZ        (1 << 6)
> > +#define              RISCV_HWPROBE_EXT_SSDTSO        (1 << 7)
> >  #define RISCV_HWPROBE_KEY_CPUPERF_0  5
> >  #define              RISCV_HWPROBE_MISALIGNED_UNKNOWN        (0 << 0)
> >  #define              RISCV_HWPROBE_MISALIGNED_EMULATED       (1 << 0)
> > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> > index c712037dbe10..c654f43b9699 100644
> > --- a/arch/riscv/kernel/sys_riscv.c
> > +++ b/arch/riscv/kernel/sys_riscv.c
> > @@ -162,6 +162,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> >               EXT_KEY(ZBB);
> >               EXT_KEY(ZBS);
> >               EXT_KEY(ZICBOZ);
> > +             EXT_KEY(SSDTSO);
> >  #undef EXT_KEY
> >       }
> >
>

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Guo Ren]

On Mon, Nov 27, 2023 at 12:16:43PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 09:51:53PM -0500, Guo Ren wrote:
> > On Fri, Nov 24, 2023 at 11:15:19AM +0100, Peter Zijlstra wrote:
> > > On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > > > From: Christoph Müllner <christoph.muellner@vrull.eu>
> > > > 
> > > > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > > > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > > > (and back). The active consistency model can therefore be switched on a
> > > > per-hart base and managed by the kernel on a per-process/thread base.
> > > 
> > > You guys, computers are hartless, nobody told ya?
> > > 
> > > > This patch implements basic Ssdtso support and adds a prctl API on top
> > > > so that user-space processes can switch to a stronger memory consistency
> > > > model (than the kernel was written for) at run-time.
> > > > 
> > > > I am not sure if other architectures support switching the memory
> > > > consistency model at run-time, but designing the prctl API in an
> > > > arch-independent way allows reusing it in the future.
> > > 
> > > IIRC some Sparc chips could do this, but I don't think anybody ever
> > > exposed this to userspace (or used it much).
> > > 
> > > IA64 had planned to do this, except they messed it up and did it the
> > > wrong way around (strong first and then relax it later), which lead to
> > > the discovery that all existing software broke (d'uh).
> > > 
> > > I think ARM64 approached this problem by adding the
> > > load-acquire/store-release instructions and for TSO based code,
> > > translate into those (eg. x86 -> arm64 transpilers).
> 
> > Keeping global TSO order is easier and faster than mixing
> > acquire/release and regular load/store. That means when ssdtso is
> > enabled, the transpiler's load-acquire/store-release becomes regular
> > load/store. Some micro-arch hardwares could speed up the performance.
> 
> Why is it faster? Because the release+acquire thing becomes RcSC instead
> of RcTSO? Surely that can be fixed with a weaker store-release variant
> ot something?
The "ld.acq + st.rel" could only be close to the ideal RCtso because
maintaining "ld.acq + st.rel + ld + st" is more complex in LSU than "ld
+ st" by global TSO.  So, that is why we want a global TSO flag to
simplify the micro-arch implementation, especially for some small
processors in the big-little system.

> 
> The problem I have with all of this is that you need to context switch
> this state and that you need to deal with exceptions, which must be
> written for the weak model but then end up running in the tso model --
> possibly slower than desired.
The s-mode TSO is useless for the riscv Linux kernel and this patch only
uses u-mode TSO. So, the exception handler and the whole kernel always
run in WMO.

Two years ago, we worried about stuff like io_uring, which means
io_uring userspace is in TSO, but the kernel side is in WMO. But it
still seems like no problem because every side has a different
implementation, but they all ensure their order. So, there should be no
problem between TSO & WMO io_uring communication. The only things we
need to prevent are:
1. Do not let the WMO code run in TSO mode, which is inefficient. (you mentioned)
2. Do not let the TSO code run in WMO mode, which is incorrect.

> If OTOH you only have a single model, everything becomes so much
> simpler. You just need to be able to express exactly what you want.
The ssdtso is no harm to the current WMO; it's just a tradeoff for
micro-arch implementation. You still could use "ld + st" are "ld.acq +
st.rl", but they are the same in the global tso state.

> 
> 
> 

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Guo Ren]

On Mon, Nov 27, 2023 at 12:16:43PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 09:51:53PM -0500, Guo Ren wrote:
> > On Fri, Nov 24, 2023 at 11:15:19AM +0100, Peter Zijlstra wrote:
> > > On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > > > From: Christoph Müllner <christoph.muellner@vrull.eu>
> > > > 
> > > > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > > > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > > > (and back). The active consistency model can therefore be switched on a
> > > > per-hart base and managed by the kernel on a per-process/thread base.
> > > 
> > > You guys, computers are hartless, nobody told ya?
> > > 
> > > > This patch implements basic Ssdtso support and adds a prctl API on top
> > > > so that user-space processes can switch to a stronger memory consistency
> > > > model (than the kernel was written for) at run-time.
> > > > 
> > > > I am not sure if other architectures support switching the memory
> > > > consistency model at run-time, but designing the prctl API in an
> > > > arch-independent way allows reusing it in the future.
> > > 
> > > IIRC some Sparc chips could do this, but I don't think anybody ever
> > > exposed this to userspace (or used it much).
> > > 
> > > IA64 had planned to do this, except they messed it up and did it the
> > > wrong way around (strong first and then relax it later), which lead to
> > > the discovery that all existing software broke (d'uh).
> > > 
> > > I think ARM64 approached this problem by adding the
> > > load-acquire/store-release instructions and for TSO based code,
> > > translate into those (eg. x86 -> arm64 transpilers).
> 
> > Keeping global TSO order is easier and faster than mixing
> > acquire/release and regular load/store. That means when ssdtso is
> > enabled, the transpiler's load-acquire/store-release becomes regular
> > load/store. Some micro-arch hardwares could speed up the performance.
> 
> Why is it faster? Because the release+acquire thing becomes RcSC instead
> of RcTSO? Surely that can be fixed with a weaker store-release variant
> ot something?
The "ld.acq + st.rel" could only be close to the ideal RCtso because
maintaining "ld.acq + st.rel + ld + st" is more complex in LSU than "ld
+ st" by global TSO.  So, that is why we want a global TSO flag to
simplify the micro-arch implementation, especially for some small
processors in the big-little system.

> 
> The problem I have with all of this is that you need to context switch
> this state and that you need to deal with exceptions, which must be
> written for the weak model but then end up running in the tso model --
> possibly slower than desired.
The s-mode TSO is useless for the riscv Linux kernel and this patch only
uses u-mode TSO. So, the exception handler and the whole kernel always
run in WMO.

Two years ago, we worried about stuff like io_uring, which means
io_uring userspace is in TSO, but the kernel side is in WMO. But it
still seems like no problem because every side has a different
implementation, but they all ensure their order. So, there should be no
problem between TSO & WMO io_uring communication. The only things we
need to prevent are:
1. Do not let the WMO code run in TSO mode, which is inefficient. (you mentioned)
2. Do not let the TSO code run in WMO mode, which is incorrect.

> If OTOH you only have a single model, everything becomes so much
> simpler. You just need to be able to express exactly what you want.
The ssdtso is no harm to the current WMO; it's just a tradeoff for
micro-arch implementation. You still could use "ld + st" are "ld.acq +
st.rl", but they are the same in the global tso state.

> 
> 
> 

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

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Andrea Parri]

On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> Unfortunately, at least last time I checked RISC-V still hadn't gotten such
> instructions.
> What they have is the *semantics* of the instructions, but no actual opcodes
> to encode them.
> I argued for them in the RISC-V memory group, but it was considered to be
> outside the scope of that group.

(Sorry for the late, late reply; just recalled this thread...)

That's right.  AFAICT, the discussion about the native load-acquire
and store-release instructions was revived somewhere last year within
the RVI community, culminating in the so called Zalasr-proposal [1];
Brendan, Hans and Andrew (+ Cc) might be able to provide more up-to-
date information about the status/plans for that proposal.

(Remark that RISC-V did introduce LR/SCs and AMOs instructions with
acquire/release semantics separately, cf. the so called A-extension.)

  Andrea

[1] https://github.com/mehnadnerd/riscv-zalasr

Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support

[Andrea Parri]

On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> Unfortunately, at least last time I checked RISC-V still hadn't gotten such
> instructions.
> What they have is the *semantics* of the instructions, but no actual opcodes
> to encode them.
> I argued for them in the RISC-V memory group, but it was considered to be
> outside the scope of that group.

(Sorry for the late, late reply; just recalled this thread...)

That's right.  AFAICT, the discussion about the native load-acquire
and store-release instructions was revived somewhere last year within
the RVI community, culminating in the so called Zalasr-proposal [1];
Brendan, Hans and Andrew (+ Cc) might be able to provide more up-to-
date information about the status/plans for that proposal.

(Remark that RISC-V did introduce LR/SCs and AMOs instructions with
acquire/release semantics separately, cf. the so called A-extension.)

  Andrea

[1] https://github.com/mehnadnerd/riscv-zalasr

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