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
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(¤t->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)
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 }
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 }
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 }
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;
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 */
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
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?!?!
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.
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?
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?!?!
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.
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.
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.
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-kselftest-mirror@lists.linaro.org
-
Christoph Muellner -
Christoph Müllner
-
Conor Dooley -
Guo Ren -
Peter Zijlstra -
Samuel Holland