Message ID | 20230521114715.955823-1-heiko.stuebner@vrull.eu |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp846438vqo; Sun, 21 May 2023 05:20:39 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7qI6Z5Nzgv32T+3eQtPrW/BB145D1OiAhtP8xsKOK/MSbrmPVRjySucBg+S6qwgyLsSgTd X-Received: by 2002:aa7:88d5:0:b0:63d:3c39:ecc2 with SMTP id k21-20020aa788d5000000b0063d3c39ecc2mr8404560pff.12.1684671638828; Sun, 21 May 2023 05:20:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684671638; cv=none; d=google.com; s=arc-20160816; b=BZIYNyFaVe1i+P5yHilEg1O7PAcBIzI0I+Yb1LazcPiQ6CjiqelOfPtHgvTbvdmV62 VFTmAVZWY5sV4VkdKNsfqefaNcqu6aNhhkq1GOs9QSO/3IzQ4VpHgNMfurqaBz6urdiR /fvUgn09pfxFQZfgsBFmBNbFtybxuSuonWwGoBZmyYBkMBVDCpaxjti4zWsog4FujcEg xAbz0B3yUbJ/VgQ7uTwZuJIM5xHKC3U19sNFYNcK9nLAxPYswLhkZf7QJYBVOhwCXnwd 3lkNVivWyLf7dig5aqo2am4SfAymqvqSa4hthXEJ0SZcF3w5wkKd7OjeEWr66iyD98aS PDzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=/RuzFKVl+QUEHLM7zKauAcPQFrNTvJTHTi/MlBJIFaA=; b=UbRLt3ZO0ranrlFbbCq0LE0s3bYQuD+hTbnDeBQiJ4w8dL+da2KbG/PO/ZGqn49trJ IG5mBSnN1E8LlTwK2z7nuREAscGopOOrje02qsV6T0gK/NcntIZeehtz5DxG8Juu4wDv rFf5A+z7uaAdieU3Am60U2d3EKpZ6R2T76ps70gpynv8hxPn9RjaxB0PNy/7SGDsteRB cFgiVVBpTmZq6oFzpLUDKBFpHwW0FLOiyaICzcrf1exgWwJEsQ6KR3A32ObUMQ007b26 bPjEIOpJ0FM09CSPg2lHX03gaLzp0gV+8JZPwzc83X6ZvgdVhp2THnc+3oT9gKNgyRry Dr2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g19-20020aa796b3000000b00643ba887601si1480613pfk.307.2023.05.21.05.20.24; Sun, 21 May 2023 05:20:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231608AbjEULug (ORCPT <rfc822;cscallsign@gmail.com> + 99 others); Sun, 21 May 2023 07:50:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231157AbjEULti (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 21 May 2023 07:49:38 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D31710F8 for <linux-kernel@vger.kernel.org>; Sun, 21 May 2023 04:47:24 -0700 (PDT) Received: from ip5b412278.dynamic.kabel-deutschland.de ([91.65.34.120] helo=phil.lan) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <heiko@sntech.de>) id 1q0hWu-0008T6-Os; Sun, 21 May 2023 13:47:16 +0200 From: Heiko Stuebner <heiko@sntech.de> To: linux-riscv@lists.infradead.org, palmer@dabbelt.com, paul.walmsley@sifive.com Cc: linux-kernel@vger.kernel.org, christoph.muellner@vrull.eu, David.Laight@ACULAB.COM, Heiko Stuebner <heiko.stuebner@vrull.eu> Subject: [PATCH v3 0/2] Add Zawrs support and use it for spinlocks Date: Sun, 21 May 2023 13:47:13 +0200 Message-Id: <20230521114715.955823-1-heiko.stuebner@vrull.eu> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_SCC_BODY_TEXT_LINE,T_SPF_HELO_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766506248519877305?= X-GMAIL-MSGID: =?utf-8?q?1766506248519877305?= |
Series |
Add Zawrs support and use it for spinlocks
|
|
Message
Heiko Stübner
May 21, 2023, 11:47 a.m. UTC
From: Heiko Stuebner <heiko.stuebner@vrull.eu>
Zawrs [0] was ratified in november 2022 [1], so I've resurrect the patch
adding Zawrs support for spinlocks and adapted it to recent kernel
changes.
Also incorporated are the nice comments David Laight provided on v2.
Changes since v2:
- Rebase on top of 6.4-rc1
- Adapt to changed alternatives Kconfig handling
- Adapt to changed cpufeature extension handling
- Address review comments from David Laight
- better handling for 32/64bit cases (less ifdefery)
- less macros calling macros
- don't duplicate __smp_load_reserved_relaxed in
__smp_load_reserved_aquire
Changes since v1:
- Fixing type checking code for 32/64-bit values
- Adjustments according to the specification change
- Adding "depends on !XIP_KERNEL" to RISCV_ISA_ZAWRS
[0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc
[1] https://github.com/riscv/riscv-zawrs/commit/9ff54f7e7fcd95cf1b111d2e54276ff1183bcd37
Christoph Müllner (1):
riscv: Add Zawrs support for spinlocks
Heiko Stuebner (1):
riscv: don't include kernel.h into alternative.h
arch/riscv/Kconfig | 10 +++++
arch/riscv/include/asm/alternative.h | 1 -
arch/riscv/include/asm/barrier.h | 64 ++++++++++++++++++++++++++++
arch/riscv/include/asm/errata_list.h | 14 ++++++
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/kernel/cpu.c | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
7 files changed, 91 insertions(+), 1 deletion(-)
Comments
On Sun, May 21, 2023 at 01:47:13PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > Zawrs [0] was ratified in november 2022 [1], so I've resurrect the patch > adding Zawrs support for spinlocks and adapted it to recent kernel > changes. > > Also incorporated are the nice comments David Laight provided on v2. > > > Changes since v2: > - Rebase on top of 6.4-rc1 > - Adapt to changed alternatives Kconfig handling > - Adapt to changed cpufeature extension handling > - Address review comments from David Laight > - better handling for 32/64bit cases (less ifdefery) > - less macros calling macros > - don't duplicate __smp_load_reserved_relaxed in > __smp_load_reserved_aquire > > Changes since v1: > - Fixing type checking code for 32/64-bit values > - Adjustments according to the specification change > - Adding "depends on !XIP_KERNEL" to RISCV_ISA_ZAWRS > > > [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc > [1] https://github.com/riscv/riscv-zawrs/commit/9ff54f7e7fcd95cf1b111d2e54276ff1183bcd37 > > Christoph Müllner (1): > riscv: Add Zawrs support for spinlocks > > Heiko Stuebner (1): > riscv: don't include kernel.h into alternative.h > > arch/riscv/Kconfig | 10 +++++ > arch/riscv/include/asm/alternative.h | 1 - > arch/riscv/include/asm/barrier.h | 64 ++++++++++++++++++++++++++++ > arch/riscv/include/asm/errata_list.h | 14 ++++++ > arch/riscv/include/asm/hwcap.h | 1 + > arch/riscv/kernel/cpu.c | 1 + > arch/riscv/kernel/cpufeature.c | 1 + > 7 files changed, 91 insertions(+), 1 deletion(-) Hi Heiko and Christoph, I was wondering about the plan for this series: am I missing some update to this discussion? do we have a new version to review? I actually went ahead (as Palmer suggested in private :-) ) and spent some time trying to integrate feedback provided in this thread into your changes, obtaining the diff below (on 6.6-rc6, the #include removal fixes some nommu builds and should/can be splitted into a separate patch); thoughts? Andrea From 79d25361ddd4a14db6ce94aec140efbdf2d89684 Mon Sep 17 00:00:00 2001 From: Andrea Parri <parri.andrea@gmail.com> Date: Wed, 18 Oct 2023 02:22:28 +0200 Subject: [PATCH] riscv: Implement LR+WRS-based smp_cond_load_{relaxed,acquire}() The Zawrs extension defines instructions allowing a core to enter a low-power state and wait on a store to a memory location. Introduce the Zawrs-instruction WRS.STO and use it in the polling loops of the macros smp_cond_load_{relaxed,acquire}(). Signed-off-by: Andrea Parri <parri.andrea@gmail.com> [based on the arm64 implementation and work from Heiko and Christoph] --- arch/riscv/Kconfig | 14 +++++++++ arch/riscv/include/asm/barrier.h | 26 ++++++++++++++++ arch/riscv/include/asm/cmpxchg.h | 51 +++++++++++++++++++++++++++++++ arch/riscv/include/asm/hwcap.h | 3 +- arch/riscv/include/asm/insn-def.h | 2 ++ arch/riscv/kernel/cpufeature.c | 1 + 6 files changed, 95 insertions(+), 2 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index d607ab0f7c6da..ff49f90d175ba 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -489,6 +489,20 @@ config RISCV_ISA_SVPBMT If you don't know what to do here, say Y. +config RISCV_ISA_ZAWRS + bool "Zawrs extension support for wait-on-reservation-set instructions" + depends on RISCV_ALTERNATIVE + default y + help + Adds support to dynamically detect the presence of the Zawrs + extension and enable its usage. + + The Zawrs extension defines a pair of instructions to be used + in polling loops that allows a core to enter a low-power state + and wait on a store to a memory location. + + If you don't know what to do here, say Y. + config TOOLCHAIN_HAS_V bool default y diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h index 110752594228e..7ab7a28e72210 100644 --- a/arch/riscv/include/asm/barrier.h +++ b/arch/riscv/include/asm/barrier.h @@ -71,6 +71,32 @@ do { \ */ #define smp_mb__after_spinlock() RISCV_FENCE(iorw,iorw) +#define smp_cond_load_relaxed(ptr, cond_expr) \ +({ \ + typeof(ptr) __PTR = (ptr); \ + __unqual_scalar_typeof(*ptr) VAL; \ + for (;;) { \ + VAL = READ_ONCE(*__PTR); \ + if (cond_expr) \ + break; \ + __cmpwait_relaxed(__PTR, VAL); \ + } \ + (typeof(*ptr))VAL; \ +}) + +#define smp_cond_load_acquire(ptr, cond_expr) \ +({ \ + typeof(ptr) __PTR = (ptr); \ + __unqual_scalar_typeof(*ptr) VAL; \ + for (;;) { \ + VAL = smp_load_acquire(__PTR); \ + if (cond_expr) \ + break; \ + __cmpwait_relaxed(__PTR, VAL); \ + } \ + (typeof(*ptr))VAL; \ +}) + #include <asm-generic/barrier.h> #endif /* __ASSEMBLY__ */ diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h index 2f4726d3cfcc2..65bc21379f40e 100644 --- a/arch/riscv/include/asm/cmpxchg.h +++ b/arch/riscv/include/asm/cmpxchg.h @@ -8,8 +8,11 @@ #include <linux/bug.h> +#include <asm/alternative-macros.h> #include <asm/barrier.h> #include <asm/fence.h> +#include <asm/hwcap.h> +#include <asm/insn-def.h> #define __xchg_relaxed(ptr, new, size) \ ({ \ @@ -360,4 +363,52 @@ arch_cmpxchg_relaxed((ptr), (o), (n)); \ }) +#define __CMPWAIT_CASE(w, sz) \ +static inline void __cmpwait_case_##sz(volatile void *ptr, \ + unsigned long val) \ +{ \ + unsigned long tmp; \ + \ + asm volatile(ALTERNATIVE( \ + __nops(4), \ + "lr." #w "\t" "%[tmp], %[v]\n\t" \ + "xor %[tmp], %[tmp], %[val]\n\t" \ + "bnez %[tmp], 1f\n\t" \ + WRS_sto "\n\t" \ + "1:\n", \ + 0, RISCV_ISA_EXT_ZAWRS, CONFIG_RISCV_ISA_ZAWRS) \ + : [tmp] "=&r" (tmp), [v] "+A" (*(u##sz *)ptr) \ + : [val] "rJ" (val) \ + : "memory"); \ +} + +__CMPWAIT_CASE(w, 32); +__CMPWAIT_CASE(d, 64); + +#undef __CMPWAIT_CASE + +#define __CMPWAIT_GEN() \ +static __always_inline void __cmpwait(volatile void *ptr, \ + unsigned long val, \ + int size) \ +{ \ + switch (size) { \ + case 4: \ + return __cmpwait_case_32(ptr, val); \ + case 8: \ + return __cmpwait_case_64(ptr, val); \ + default: \ + BUILD_BUG(); \ + } \ + \ + unreachable(); \ +} + +__CMPWAIT_GEN() + +#undef __CMPWAIT_GEN + +#define __cmpwait_relaxed(ptr, val) \ + __cmpwait((ptr), (unsigned long)(val), sizeof(*(ptr))) + #endif /* _ASM_RISCV_CMPXCHG_H */ diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index b7b58258f6c7c..afabcbf849526 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -58,6 +58,7 @@ #define RISCV_ISA_EXT_ZICSR 40 #define RISCV_ISA_EXT_ZIFENCEI 41 #define RISCV_ISA_EXT_ZIHPM 42 +#define RISCV_ISA_EXT_ZAWRS 43 #define RISCV_ISA_EXT_MAX 64 @@ -69,8 +70,6 @@ #ifndef __ASSEMBLY__ -#include <linux/jump_label.h> - unsigned long riscv_get_elf_hwcap(void); struct riscv_isa_ext_data { diff --git a/arch/riscv/include/asm/insn-def.h b/arch/riscv/include/asm/insn-def.h index 6960beb75f329..fecb744ed7b29 100644 --- a/arch/riscv/include/asm/insn-def.h +++ b/arch/riscv/include/asm/insn-def.h @@ -196,4 +196,6 @@ INSN_I(OPCODE_MISC_MEM, FUNC3(2), __RD(0), \ RS1(base), SIMM12(4)) +#define WRS_sto ".long 0x01d00073" + #endif /* __ASM_INSN_DEF_H */ diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index 1cfbba65d11ae..044682f54f78f 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(svinval, RISCV_ISA_EXT_SVINVAL), __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT), __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), + __RISCV_ISA_EXT_DATA(zawrs, RISCV_ISA_EXT_ZAWRS), }; const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
On Thu, Oct 19, 2023 at 4:21 PM Andrea Parri <parri.andrea@gmail.com> wrote: > > On Sun, May 21, 2023 at 01:47:13PM +0200, Heiko Stuebner wrote: > > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > > > Zawrs [0] was ratified in november 2022 [1], so I've resurrect the patch > > adding Zawrs support for spinlocks and adapted it to recent kernel > > changes. > > > > Also incorporated are the nice comments David Laight provided on v2. > > > > > > Changes since v2: > > - Rebase on top of 6.4-rc1 > > - Adapt to changed alternatives Kconfig handling > > - Adapt to changed cpufeature extension handling > > - Address review comments from David Laight > > - better handling for 32/64bit cases (less ifdefery) > > - less macros calling macros > > - don't duplicate __smp_load_reserved_relaxed in > > __smp_load_reserved_aquire > > > > Changes since v1: > > - Fixing type checking code for 32/64-bit values > > - Adjustments according to the specification change > > - Adding "depends on !XIP_KERNEL" to RISCV_ISA_ZAWRS > > > > > > [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc > > [1] https://github.com/riscv/riscv-zawrs/commit/9ff54f7e7fcd95cf1b111d2e54276ff1183bcd37 > > > > Christoph Müllner (1): > > riscv: Add Zawrs support for spinlocks > > > > Heiko Stuebner (1): > > riscv: don't include kernel.h into alternative.h > > > > arch/riscv/Kconfig | 10 +++++ > > arch/riscv/include/asm/alternative.h | 1 - > > arch/riscv/include/asm/barrier.h | 64 ++++++++++++++++++++++++++++ > > arch/riscv/include/asm/errata_list.h | 14 ++++++ > > arch/riscv/include/asm/hwcap.h | 1 + > > arch/riscv/kernel/cpu.c | 1 + > > arch/riscv/kernel/cpufeature.c | 1 + > > 7 files changed, 91 insertions(+), 1 deletion(-) > > > Hi Heiko and Christoph, > > I was wondering about the plan for this series: am I missing some update to > this discussion? do we have a new version to review? Hi Andrea, Thanks for reaching out! We have this on the list of tasks that we would like to work on, but as this currently has low priority for us, we don't have a date when we can come up with a revised patch. > I actually went ahead (as Palmer suggested in private :-) ) and spent some > time trying to integrate feedback provided in this thread into your changes, > obtaining the diff below (on 6.6-rc6, the #include removal fixes some nommu > builds and should/can be splitted into a separate patch); thoughts? I had a quick look at your changes, and they look good to me. Did you agree with Palmer about testing requirements? I.e., do we need to run this on hardware that implements Zawrs in a non-trivial way? I can try to raise the priority on this here, but can't promise anything. For me it is also ok if you take over this patchset. BR Christoph > > Andrea > > > From 79d25361ddd4a14db6ce94aec140efbdf2d89684 Mon Sep 17 00:00:00 2001 > From: Andrea Parri <parri.andrea@gmail.com> > Date: Wed, 18 Oct 2023 02:22:28 +0200 > Subject: [PATCH] riscv: Implement LR+WRS-based smp_cond_load_{relaxed,acquire}() > > The Zawrs extension defines instructions allowing a core to enter > a low-power state and wait on a store to a memory location. > > Introduce the Zawrs-instruction WRS.STO and use it in the polling > loops of the macros smp_cond_load_{relaxed,acquire}(). > > Signed-off-by: Andrea Parri <parri.andrea@gmail.com> > [based on the arm64 implementation and work from Heiko and Christoph] > --- > arch/riscv/Kconfig | 14 +++++++++ > arch/riscv/include/asm/barrier.h | 26 ++++++++++++++++ > arch/riscv/include/asm/cmpxchg.h | 51 +++++++++++++++++++++++++++++++ > arch/riscv/include/asm/hwcap.h | 3 +- > arch/riscv/include/asm/insn-def.h | 2 ++ > arch/riscv/kernel/cpufeature.c | 1 + > 6 files changed, 95 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index d607ab0f7c6da..ff49f90d175ba 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -489,6 +489,20 @@ config RISCV_ISA_SVPBMT > > If you don't know what to do here, say Y. > > +config RISCV_ISA_ZAWRS > + bool "Zawrs extension support for wait-on-reservation-set instructions" > + depends on RISCV_ALTERNATIVE > + default y > + help > + Adds support to dynamically detect the presence of the Zawrs > + extension and enable its usage. > + > + The Zawrs extension defines a pair of instructions to be used > + in polling loops that allows a core to enter a low-power state > + and wait on a store to a memory location. > + > + If you don't know what to do here, say Y. > + > config TOOLCHAIN_HAS_V > bool > default y > diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h > index 110752594228e..7ab7a28e72210 100644 > --- a/arch/riscv/include/asm/barrier.h > +++ b/arch/riscv/include/asm/barrier.h > @@ -71,6 +71,32 @@ do { \ > */ > #define smp_mb__after_spinlock() RISCV_FENCE(iorw,iorw) > > +#define smp_cond_load_relaxed(ptr, cond_expr) \ > +({ \ > + typeof(ptr) __PTR = (ptr); \ > + __unqual_scalar_typeof(*ptr) VAL; \ > + for (;;) { \ > + VAL = READ_ONCE(*__PTR); \ > + if (cond_expr) \ > + break; \ > + __cmpwait_relaxed(__PTR, VAL); \ > + } \ > + (typeof(*ptr))VAL; \ > +}) > + > +#define smp_cond_load_acquire(ptr, cond_expr) \ > +({ \ > + typeof(ptr) __PTR = (ptr); \ > + __unqual_scalar_typeof(*ptr) VAL; \ > + for (;;) { \ > + VAL = smp_load_acquire(__PTR); \ > + if (cond_expr) \ > + break; \ > + __cmpwait_relaxed(__PTR, VAL); \ > + } \ > + (typeof(*ptr))VAL; \ > +}) > + > #include <asm-generic/barrier.h> > > #endif /* __ASSEMBLY__ */ > diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h > index 2f4726d3cfcc2..65bc21379f40e 100644 > --- a/arch/riscv/include/asm/cmpxchg.h > +++ b/arch/riscv/include/asm/cmpxchg.h > @@ -8,8 +8,11 @@ > > #include <linux/bug.h> > > +#include <asm/alternative-macros.h> > #include <asm/barrier.h> > #include <asm/fence.h> > +#include <asm/hwcap.h> > +#include <asm/insn-def.h> > > #define __xchg_relaxed(ptr, new, size) \ > ({ \ > @@ -360,4 +363,52 @@ > arch_cmpxchg_relaxed((ptr), (o), (n)); \ > }) > > +#define __CMPWAIT_CASE(w, sz) \ > +static inline void __cmpwait_case_##sz(volatile void *ptr, \ > + unsigned long val) \ > +{ \ > + unsigned long tmp; \ > + \ > + asm volatile(ALTERNATIVE( \ > + __nops(4), \ > + "lr." #w "\t" "%[tmp], %[v]\n\t" \ > + "xor %[tmp], %[tmp], %[val]\n\t" \ > + "bnez %[tmp], 1f\n\t" \ > + WRS_sto "\n\t" \ > + "1:\n", \ > + 0, RISCV_ISA_EXT_ZAWRS, CONFIG_RISCV_ISA_ZAWRS) \ > + : [tmp] "=&r" (tmp), [v] "+A" (*(u##sz *)ptr) \ > + : [val] "rJ" (val) \ > + : "memory"); \ > +} > + > +__CMPWAIT_CASE(w, 32); > +__CMPWAIT_CASE(d, 64); > + > +#undef __CMPWAIT_CASE > + > +#define __CMPWAIT_GEN() \ > +static __always_inline void __cmpwait(volatile void *ptr, \ > + unsigned long val, \ > + int size) \ > +{ \ > + switch (size) { \ > + case 4: \ > + return __cmpwait_case_32(ptr, val); \ > + case 8: \ > + return __cmpwait_case_64(ptr, val); \ > + default: \ > + BUILD_BUG(); \ > + } \ > + \ > + unreachable(); \ > +} > + > +__CMPWAIT_GEN() > + > +#undef __CMPWAIT_GEN > + > +#define __cmpwait_relaxed(ptr, val) \ > + __cmpwait((ptr), (unsigned long)(val), sizeof(*(ptr))) > + > #endif /* _ASM_RISCV_CMPXCHG_H */ > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > index b7b58258f6c7c..afabcbf849526 100644 > --- a/arch/riscv/include/asm/hwcap.h > +++ b/arch/riscv/include/asm/hwcap.h > @@ -58,6 +58,7 @@ > #define RISCV_ISA_EXT_ZICSR 40 > #define RISCV_ISA_EXT_ZIFENCEI 41 > #define RISCV_ISA_EXT_ZIHPM 42 > +#define RISCV_ISA_EXT_ZAWRS 43 > > #define RISCV_ISA_EXT_MAX 64 > > @@ -69,8 +70,6 @@ > > #ifndef __ASSEMBLY__ > > -#include <linux/jump_label.h> > - > unsigned long riscv_get_elf_hwcap(void); > > struct riscv_isa_ext_data { > diff --git a/arch/riscv/include/asm/insn-def.h b/arch/riscv/include/asm/insn-def.h > index 6960beb75f329..fecb744ed7b29 100644 > --- a/arch/riscv/include/asm/insn-def.h > +++ b/arch/riscv/include/asm/insn-def.h > @@ -196,4 +196,6 @@ > INSN_I(OPCODE_MISC_MEM, FUNC3(2), __RD(0), \ > RS1(base), SIMM12(4)) > > +#define WRS_sto ".long 0x01d00073" > + > #endif /* __ASM_INSN_DEF_H */ > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index 1cfbba65d11ae..044682f54f78f 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(svinval, RISCV_ISA_EXT_SVINVAL), > __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT), > __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), > + __RISCV_ISA_EXT_DATA(zawrs, RISCV_ISA_EXT_ZAWRS), > }; > > const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext); > -- > 2.34.1 >
(Removing Heiko's @vrull address from Cc:, since it seemed to bounce, keeping his @sntech address.) > I had a quick look at your changes, and they look good to me. Great. Thank you for looking them over. > Did you agree with Palmer about testing requirements? > I.e., do we need to run this on hardware that implements Zawrs in a > non-trivial way? I didn't quite discuss such specific requirements or hardware implementations, but I agree that's a valid concern. Not that I currently have access to such hardware; any further inputs/data will be appreciated. > I can try to raise the priority on this here, but can't promise anything. > For me it is also ok if you take over this patchset. Thanks. Either way works for me. No urgency from my side. I'd say - let us leave this up to the community/other reviewers. (IIUC, Palmer was recovering from a certain flu and might need more time than usual to get back here.) Andrea
On Fri, Oct 20, 2023 at 12:19:38PM +0200, Andrea Parri wrote: > (Removing Heiko's @vrull address from Cc:, since it seemed to bounce, keeping > his @sntech address.) > > > I had a quick look at your changes, and they look good to me. > > Great. Thank you for looking them over. > > > Did you agree with Palmer about testing requirements? > > I.e., do we need to run this on hardware that implements Zawrs in a > > non-trivial way? > > I didn't quite discuss such specific requirements or hardware implementations, > but I agree that's a valid concern. Not that I currently have access to such > hardware; any further inputs/data will be appreciated. > > > I can try to raise the priority on this here, but can't promise anything. > > For me it is also ok if you take over this patchset. > > Thanks. Either way works for me. No urgency from my side. I'd say - let us > leave this up to the community/other reviewers. (IIUC, Palmer was recovering > from a certain flu and might need more time than usual to get back here.) > Hi everyone, I'm also interested in seeing this series resurrected and making progress again. I'd be happy to help out in any way. It's not clear to me if it has a current owner. If not, then I could start shepherding the patches with their authorships intact. I may be able to do some testing on an FPGA too. Thanks, drew
Hi Andrew, > > > I can try to raise the priority on this here, but can't promise anything. > > > For me it is also ok if you take over this patchset. > > > > Thanks. Either way works for me. No urgency from my side. I'd say - let us > > leave this up to the community/other reviewers. (IIUC, Palmer was recovering > > from a certain flu and might need more time than usual to get back here.) > > > > Hi everyone, > > I'm also interested in seeing this series resurrected and making progress > again. I'd be happy to help out in any way. It's not clear to me if it has > a current owner. If not, then I could start shepherding the patches with > their authorships intact. This sounds great to me - please do! I don't have additional information to provide about this matter. Thanks! Andrea
On Mon, Jan 8, 2024 at 12:35 PM Andrew Jones <ajones@ventanamicro.com> wrote: > > On Fri, Oct 20, 2023 at 12:19:38PM +0200, Andrea Parri wrote: > > (Removing Heiko's @vrull address from Cc:, since it seemed to bounce, keeping > > his @sntech address.) > > > > > I had a quick look at your changes, and they look good to me. > > > > Great. Thank you for looking them over. > > > > > Did you agree with Palmer about testing requirements? > > > I.e., do we need to run this on hardware that implements Zawrs in a > > > non-trivial way? > > > > I didn't quite discuss such specific requirements or hardware implementations, > > but I agree that's a valid concern. Not that I currently have access to such > > hardware; any further inputs/data will be appreciated. > > > > > I can try to raise the priority on this here, but can't promise anything. > > > For me it is also ok if you take over this patchset. > > > > Thanks. Either way works for me. No urgency from my side. I'd say - let us > > leave this up to the community/other reviewers. (IIUC, Palmer was recovering > > from a certain flu and might need more time than usual to get back here.) > > > > Hi everyone, > > I'm also interested in seeing this series resurrected and making progress > again. I'd be happy to help out in any way. It's not clear to me if it has > a current owner. If not, then I could start shepherding the patches with > their authorships intact. Sounds good to me! Thanks for working on this! > > I may be able to do some testing on an FPGA too. > > Thanks, > drew
On Mon, Jan 08, 2024 at 03:00:29PM +0100, Christoph Müllner wrote: > On Mon, Jan 8, 2024 at 12:35 PM Andrew Jones <ajones@ventanamicro.com> wrote: > > > > On Fri, Oct 20, 2023 at 12:19:38PM +0200, Andrea Parri wrote: > > > (Removing Heiko's @vrull address from Cc:, since it seemed to bounce, keeping > > > his @sntech address.) > > > > > > > I had a quick look at your changes, and they look good to me. > > > > > > Great. Thank you for looking them over. > > > > > > > Did you agree with Palmer about testing requirements? > > > > I.e., do we need to run this on hardware that implements Zawrs in a > > > > non-trivial way? > > > > > > I didn't quite discuss such specific requirements or hardware implementations, > > > but I agree that's a valid concern. Not that I currently have access to such > > > hardware; any further inputs/data will be appreciated. > > > > > > > I can try to raise the priority on this here, but can't promise anything. > > > > For me it is also ok if you take over this patchset. > > > > > > Thanks. Either way works for me. No urgency from my side. I'd say - let us > > > leave this up to the community/other reviewers. (IIUC, Palmer was recovering > > > from a certain flu and might need more time than usual to get back here.) > > > > > > > Hi everyone, > > > > I'm also interested in seeing this series resurrected and making progress > > again. I'd be happy to help out in any way. It's not clear to me if it has > > a current owner. If not, then I could start shepherding the patches with > > their authorships intact. > > Sounds good to me! > Thanks for working on this! Thanks for the quick replies! I'll try pull something together in the very near future. drew > > > > > I may be able to do some testing on an FPGA too. > > > > Thanks, > > drew