From: Jan Beulich <jbeulich@suse.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
Bob Eshleman <bobbyeshleman@gmail.com>,
Connor Davis <connojdavis@gmail.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 13/23] xen/riscv: introduce atomic.h
Date: Wed, 6 Mar 2024 16:31:56 +0100 [thread overview]
Message-ID: <3d9b0fa3-d100-4e73-b5d5-782ef58e331a@suse.com> (raw)
In-Reply-To: <85ad8c86901d045beed228947d4c3faf277af3ca.1708962629.git.oleksii.kurochko@gmail.com>
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/atomic.h
> @@ -0,0 +1,296 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Taken and modified from Linux.
> + *
> + * The following changes were done:
> + * - * atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
> + * to use__*xchg_generic()
> + * - drop casts in write_atomic() as they are unnecessary
> + * - drop introduction of WRITE_ONCE() and READ_ONCE().
> + * Xen provides ACCESS_ONCE()
> + * - remove zero-length array access in read_atomic()
> + * - drop defines similar to pattern
> + * #define atomic_add_return_relaxed atomic_add_return_relaxed
> + * - move not RISC-V specific functions to asm-generic/atomics-ops.h
> + *
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Copyright (C) 2012 Regents of the University of California
> + * Copyright (C) 2017 SiFive
> + * Copyright (C) 2024 Vates SAS
> + */
> +
> +#ifndef _ASM_RISCV_ATOMIC_H
> +#define _ASM_RISCV_ATOMIC_H
> +
> +#include <xen/atomic.h>
> +
> +#include <asm/cmpxchg.h>
> +#include <asm/fence.h>
> +#include <asm/io.h>
> +#include <asm/system.h>
> +
> +#include <asm-generic/atomic-ops.h>
While, because of the forward decls in xen/atomic.h, having this #include
works, I wonder if it wouldn't better be placed further down. The compiler
will likely have an easier time when it sees the inline definitions ahead
of any uses.
> +void __bad_atomic_size(void);
> +
> +/*
> + * Legacy from Linux kernel. For some reason they wanted to have ordered
> + * read/write access. Thereby read* is used instead of read<X>_cpu()
> + */
> +static always_inline void read_atomic_size(const volatile void *p,
> + void *res,
> + unsigned int size)
> +{
> + switch ( size )
> + {
> + case 1: *(uint8_t *)res = readb(p); break;
> + case 2: *(uint16_t *)res = readw(p); break;
> + case 4: *(uint32_t *)res = readl(p); break;
> + case 8: *(uint32_t *)res = readq(p); break;
This is the point where the lack of constraints in io.h (see my respective
comment) becomes actually harmful: You're accessing not MMIO, but compiler-
visible variables here. It needs to know which ones are read ...
> + default: __bad_atomic_size(); break;
> + }
> +}
> +
> +#define read_atomic(p) ({ \
> + union { typeof(*p) val; char c[sizeof(*p)]; } x_; \
> + read_atomic_size(p, x_.c, sizeof(*p)); \
> + x_.val; \
> +})
> +
> +#define write_atomic(p, x) \
> +({ \
> + typeof(*p) x__ = (x); \
> + switch ( sizeof(*p) ) \
> + { \
> + case 1: writeb(x__, p); break; \
> + case 2: writew(x__, p); break; \
> + case 4: writel(x__, p); break; \
> + case 8: writeq(x__, p); break; \
... or written.
Nit: There's a stray blank in the writeb() invocation.
> + default: __bad_atomic_size(); break; \
> + } \
> + x__; \
> +})
> +
> +#define add_sized(p, x) \
> +({ \
> + typeof(*(p)) x__ = (x); \
> + switch ( sizeof(*(p)) ) \
Like you have it here, {read,write}_atomic() also need p properly
parenthesized. There look to be more parenthesization issues further
down.
> + { \
> + case 1: writeb(read_atomic(p) + x__, p); break; \
> + case 2: writew(read_atomic(p) + x__, p); break; \
> + case 4: writel(read_atomic(p) + x__, p); break; \
> + default: __bad_atomic_size(); break; \
> + } \
> +})
Any reason this doesn't have an 8-byte case? x86'es at least has one.
> +#define __atomic_acquire_fence() \
> + __asm__ __volatile__ ( RISCV_ACQUIRE_BARRIER "" ::: "memory" )
> +
> +#define __atomic_release_fence() \
> + __asm__ __volatile__ ( RISCV_RELEASE_BARRIER "" ::: "memory" )
Elsewhere you use asm volatile() - why __asm__ __volatile__() here?
Or why not there (cmpxchg.h, io.h)?
> +/*
> + * First, the atomic ops that have no ordering constraints and therefor don't
> + * have the AQ or RL bits set. These don't return anything, so there's only
> + * one version to worry about.
> + */
> +#define ATOMIC_OP(op, asm_op, I, asm_type, c_type, prefix) \
> +static inline \
> +void atomic##prefix##_##op(c_type i, atomic##prefix##_t *v) \
> +{ \
> + __asm__ __volatile__ ( \
> + " amo" #asm_op "." #asm_type " zero, %1, %0" \
> + : "+A" (v->counter) \
> + : "r" (I) \
> + : "memory" ); \
> +} \
> +
> +#define ATOMIC_OPS(op, asm_op, I) \
> + ATOMIC_OP (op, asm_op, I, w, int, )
> +
> +ATOMIC_OPS(add, add, i)
> +ATOMIC_OPS(sub, add, -i)
> +ATOMIC_OPS(and, and, i)
> +ATOMIC_OPS( or, or, i)
> +ATOMIC_OPS(xor, xor, i)
> +
> +#undef ATOMIC_OP
> +#undef ATOMIC_OPS
> +
> +/*
> + * Atomic ops that have ordered, relaxed, acquire, and release variants.
> + * There's two flavors of these: the arithmatic ops have both fetch and return
> + * versions, while the logical ops only have fetch versions.
> + */
> +#define ATOMIC_FETCH_OP(op, asm_op, I, asm_type, c_type, prefix) \
> +static inline \
> +c_type atomic##prefix##_fetch_##op##_relaxed(c_type i, \
> + atomic##prefix##_t *v) \
> +{ \
> + register c_type ret; \
> + __asm__ __volatile__ ( \
> + " amo" #asm_op "." #asm_type " %1, %2, %0" \
> + : "+A" (v->counter), "=r" (ret) \
> + : "r" (I) \
> + : "memory" ); \
> + return ret; \
> +} \
> +static inline \
> +c_type atomic##prefix##_fetch_##op(c_type i, atomic##prefix##_t *v) \
> +{ \
> + register c_type ret; \
> + __asm__ __volatile__ ( \
> + " amo" #asm_op "." #asm_type ".aqrl %1, %2, %0" \
> + : "+A" (v->counter), "=r" (ret) \
> + : "r" (I) \
> + : "memory" ); \
> + return ret; \
> +}
> +
> +#define ATOMIC_OP_RETURN(op, asm_op, c_op, I, asm_type, c_type, prefix) \
> +static inline \
> +c_type atomic##prefix##_##op##_return_relaxed(c_type i, \
> + atomic##prefix##_t *v) \
> +{ \
> + return atomic##prefix##_fetch_##op##_relaxed(i, v) c_op I; \
> +} \
> +static inline \
> +c_type atomic##prefix##_##op##_return(c_type i, atomic##prefix##_t *v) \
> +{ \
> + return atomic##prefix##_fetch_##op(i, v) c_op I; \
> +}
> +
> +#define ATOMIC_OPS(op, asm_op, c_op, I) \
> + ATOMIC_FETCH_OP( op, asm_op, I, w, int, ) \
> + ATOMIC_OP_RETURN(op, asm_op, c_op, I, w, int, )
What purpose is the last macro argument when you only ever pass nothing
for it (here and ...
> +ATOMIC_OPS(add, add, +, i)
> +ATOMIC_OPS(sub, add, +, -i)
> +
> +#undef ATOMIC_OPS
> +
> +#define ATOMIC_OPS(op, asm_op, I) \
> + ATOMIC_FETCH_OP(op, asm_op, I, w, int, )
... here)?
> +ATOMIC_OPS(and, and, i)
> +ATOMIC_OPS( or, or, i)
> +ATOMIC_OPS(xor, xor, i)
> +
> +#undef ATOMIC_OPS
> +
> +#undef ATOMIC_FETCH_OP
> +#undef ATOMIC_OP_RETURN
> +
> +/* This is required to provide a full barrier on success. */
> +static inline int atomic_add_unless(atomic_t *v, int a, int u)
> +{
> + int prev, rc;
> +
> + __asm__ __volatile__ (
> + "0: lr.w %[p], %[c]\n"
> + " beq %[p], %[u], 1f\n"
> + " add %[rc], %[p], %[a]\n"
> + " sc.w.rl %[rc], %[rc], %[c]\n"
> + " bnez %[rc], 0b\n"
> + RISCV_FULL_BARRIER
> + "1:\n"
> + : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter)
> + : [a] "r" (a), [u] "r" (u)
> + : "memory");
> + return prev;
> +}
> +
> +/*
> + * atomic_{cmp,}xchg is required to have exactly the same ordering semantics as
> + * {cmp,}xchg and the operations that return, so they need a full barrier.
> + */
> +#define ATOMIC_OP(c_t, prefix, size) \
> +static inline \
> +c_t atomic##prefix##_xchg_relaxed(atomic##prefix##_t *v, c_t n) \
> +{ \
> + return __xchg_generic(&(v->counter), n, size, "", "", ""); \
The inner parentheses aren't really needed here, are they?
> +} \
> +static inline \
> +c_t atomic##prefix##_xchg_acquire(atomic##prefix##_t *v, c_t n) \
> +{ \
> + return __xchg_generic(&(v->counter), n, size, \
> + "", "", RISCV_ACQUIRE_BARRIER); \
> +} \
> +static inline \
> +c_t atomic##prefix##_xchg_release(atomic##prefix##_t *v, c_t n) \
> +{ \
> + return __xchg_generic(&(v->counter), n, size, \
> + "", RISCV_RELEASE_BARRIER, ""); \
> +} \
> +static inline \
> +c_t atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n) \
> +{ \
> + return __xchg_generic(&(v->counter), n, size, \
> + ".aqrl", "", ""); \
> +} \
> +static inline \
> +c_t atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v, \
> + c_t o, c_t n) \
> +{ \
> + return __cmpxchg_generic(&(v->counter), o, n, size, \
> + "", "", ""); \
> +} \
> +static inline \
> +c_t atomic##prefix##_cmpxchg_acquire(atomic##prefix##_t *v, \
> + c_t o, c_t n) \
> +{ \
> + return __cmpxchg_generic(&(v->counter), o, n, size, \
> + "", "", RISCV_ACQUIRE_BARRIER); \
> +} \
> +static inline \
> +c_t atomic##prefix##_cmpxchg_release(atomic##prefix##_t *v, \
> + c_t o, c_t n) \
> +{ \
A hard tab looks to have been left here.
> + return __cmpxchg_generic(&(v->counter), o, n, size, \
> + "", RISCV_RELEASE_BARRIER, ""); \
> +} \
> +static inline \
> +c_t atomic##prefix##_cmpxchg(atomic##prefix##_t *v, c_t o, c_t n) \
> +{ \
> + return __cmpxchg_generic(&(v->counter), o, n, size, \
> + ".rl", "", " fence rw, rw\n"); \
> +}
> +
> +#define ATOMIC_OPS() \
> + ATOMIC_OP(int, , 4)
> +
> +ATOMIC_OPS()
> +
> +#undef ATOMIC_OPS
> +#undef ATOMIC_OP
> +
> +static inline int atomic_sub_if_positive(atomic_t *v, int offset)
> +{
> + int prev, rc;
> +
> + __asm__ __volatile__ (
> + "0: lr.w %[p], %[c]\n"
> + " sub %[rc], %[p], %[o]\n"
> + " bltz %[rc], 1f\n"
> + " sc.w.rl %[rc], %[rc], %[c]\n"
> + " bnez %[rc], 0b\n"
> + " fence rw, rw\n"
> + "1:\n"
> + : [p] "=&r" (prev), [rc] "=&r" (rc), [c] "+A" (v->counter)
> + : [o] "r" (offset)
> + : "memory" );
> + return prev - offset;
> +}
> +
> +#define atomic_dec_if_positive(v) atomic_sub_if_positive(v, 1)
Hmm, PPC for some reason also has the latter, but for both: Are they indeed
going to be needed in RISC-V code? They certainly look unnecessary for the
purpose of this series (allowing common code to build).
> --- /dev/null
> +++ b/xen/include/asm-generic/atomic-ops.h
> @@ -0,0 +1,92 @@
> +#/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_GENERIC_ATOMIC_OPS_H_
> +#define _ASM_GENERIC_ATOMIC_OPS_H_
> +
> +#include <xen/atomic.h>
> +#include <xen/lib.h>
If I'm not mistaken this header provides default implementations for every
xen/atomic.h-provided forward inline declaration that can be synthesized
from other atomic functions. I think a comment to this effect would want
adding somewhere here.
Jan
next prev parent reply other threads:[~2024-03-06 15:32 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 17:38 [PATCH v5 00/23] [PATCH v4 00/30] Enable build of full Xen for RISC-V Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 01/23] xen/riscv: disable unnecessary configs Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 02/23] xen/riscv: use some asm-generic headers Oleksii Kurochko
2024-02-27 7:35 ` Jan Beulich
2024-02-26 17:38 ` [PATCH v5 03/23] xen/riscv: introduce nospec.h Oleksii Kurochko
2024-02-27 7:38 ` Jan Beulich
2024-02-28 9:59 ` Oleksii
2024-02-29 13:49 ` Julien Grall
2024-02-29 14:01 ` Jan Beulich
2024-02-29 16:09 ` Oleksii
2024-02-29 16:27 ` Jan Beulich
2024-02-26 17:38 ` [PATCH v5 04/23] xen/asm-generic: introduce generic fls() and flsl() functions Oleksii Kurochko
2024-02-29 13:54 ` Julien Grall
2024-02-29 14:03 ` Jan Beulich
2024-02-29 14:08 ` Julien Grall
2024-02-29 16:17 ` Oleksii
2024-02-29 15:52 ` Jan Beulich
2024-02-29 16:25 ` Andrew Cooper
2024-03-01 9:15 ` Oleksii
2024-02-26 17:38 ` [PATCH v5 05/23] xen/asm-generic: introduce generic find first set bit functions Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 06/23] xen/asm-generic: introduce generic ffz() Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 07/23] xen/asm-generic: introduce generic hweight64() Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 08/23] xen/asm-generic: introduce generic non-atomic test_*bit() Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 09/23] xen/riscv: introduce bitops.h Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 10/23] xen/riscv: introduces acrquire, release and full barriers Oleksii Kurochko
2024-03-05 7:42 ` Jan Beulich
2024-02-26 17:38 ` [PATCH v5 11/23] xen/riscv: introduce cmpxchg.h Oleksii Kurochko
2024-03-06 14:56 ` Jan Beulich
2024-03-07 10:35 ` Oleksii
2024-03-07 10:46 ` Jan Beulich
2024-03-07 11:01 ` Oleksii
2024-03-07 11:11 ` Jan Beulich
2024-03-07 12:28 ` Oleksii
2024-02-26 17:38 ` [PATCH v5 12/23] xen/riscv: introduce io.h Oleksii Kurochko
2024-03-06 14:13 ` Jan Beulich
2024-03-07 13:01 ` Oleksii
2024-03-07 13:24 ` Jan Beulich
2024-03-07 13:44 ` Oleksii
2024-03-07 15:32 ` Jan Beulich
2024-03-07 16:21 ` Oleksii
2024-03-07 17:14 ` Jan Beulich
2024-03-07 20:49 ` Oleksii
2024-03-07 20:54 ` Oleksii
2024-03-08 7:26 ` Jan Beulich
2024-03-08 10:14 ` Oleksii
2024-03-08 11:49 ` Jan Beulich
2024-03-08 11:52 ` Jan Beulich
2024-03-08 12:17 ` Oleksii
2024-03-08 12:54 ` Jan Beulich
2024-03-08 7:18 ` Jan Beulich
2024-02-26 17:38 ` [PATCH v5 13/23] xen/riscv: introduce atomic.h Oleksii Kurochko
2024-03-06 15:31 ` Jan Beulich [this message]
2024-03-07 13:30 ` Oleksii
2024-03-07 15:40 ` Jan Beulich
2024-02-26 17:38 ` [PATCH v5 14/23] xen/riscv: introduce monitor.h Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 15/23] xen/riscv: add definition of __read_mostly Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 16/23] xen/riscv: add required things to current.h Oleksii Kurochko
2024-02-26 17:38 ` [PATCH v5 17/23] xen/riscv: add minimal stuff to page.h to build full Xen Oleksii Kurochko
2024-02-26 17:39 ` [PATCH v5 18/23] xen/riscv: add minimal stuff to processor.h " Oleksii Kurochko
2024-03-05 8:05 ` Jan Beulich
2024-03-05 17:34 ` Oleksii
2024-02-26 17:39 ` [PATCH v5 19/23] xen/riscv: add minimal stuff to mm.h " Oleksii Kurochko
2024-03-05 8:17 ` Jan Beulich
2024-03-05 16:46 ` Oleksii
2024-02-26 17:39 ` [PATCH v5 20/23] xen/riscv: introduce vm_event_*() functions Oleksii Kurochko
2024-02-26 17:39 ` [PATCH v5 21/23] xen/rirscv: add minimal amount of stubs to build full Xen Oleksii Kurochko
2024-03-05 8:40 ` Jan Beulich
2024-02-26 17:39 ` [PATCH v5 22/23] xen/riscv: enable full Xen build Oleksii Kurochko
2024-02-26 17:39 ` [PATCH v5 23/23] xen/README: add compiler and binutils versions for RISC-V64 Oleksii Kurochko
2024-02-27 7:55 ` Jan Beulich
2024-02-28 17:03 ` Oleksii
2024-02-28 22:58 ` Julien Grall
2024-02-28 23:11 ` Andrew Cooper
2024-02-29 17:00 ` Oleksii
2024-02-29 7:58 ` Jan Beulich
2024-02-29 10:23 ` Julien Grall
2024-02-29 11:56 ` Jan Beulich
2024-02-29 11:59 ` Jan Beulich
2024-02-29 12:05 ` Andrew Cooper
2024-02-29 12:17 ` Jan Beulich
2024-02-29 12:32 ` Julien Grall
2024-02-29 12:51 ` Jan Beulich
2024-02-29 13:44 ` Julien Grall
2024-02-29 14:07 ` Jan Beulich
2024-02-29 14:14 ` Julien Grall
2024-02-29 17:43 ` Stefano Stabellini
2024-02-29 12:27 ` Julien Grall
2024-02-29 16:54 ` Oleksii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d9b0fa3-d100-4e73-b5d5-782ef58e331a@suse.com \
--to=jbeulich@suse.com \
--cc=alistair.francis@wdc.com \
--cc=andrew.cooper3@citrix.com \
--cc=bobbyeshleman@gmail.com \
--cc=connojdavis@gmail.com \
--cc=george.dunlap@citrix.com \
--cc=julien@xen.org \
--cc=oleksii.kurochko@gmail.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.