qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 02/54] accel/tcg: Honor atomicity of loads


From: Peter Maydell
Subject: Re: [PATCH v5 02/54] accel/tcg: Honor atomicity of loads
Date: Tue, 16 May 2023 14:13:57 +0100

On Mon, 15 May 2023 at 15:35, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Create ldst_atomicity.c.inc.
>
> Not required for user-only code loads, because we've ensured that
> the page is read-only before beginning to translate code.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> v5: Dropped r-b because of MO_ATOM_* reorg
> ---

> +/**
> + * load_atomic16:
> + * @pv: host address
> + *
> + * Atomically load 16 aligned bytes from @pv.
> + */
> +static inline Int128 load_atomic16(void *pv)
> +{
> +#ifdef CONFIG_ATOMIC128
> +    __uint128_t *p = __builtin_assume_aligned(pv, 16);
> +    Int128Alias r;
> +
> +    r.u = qatomic_read__nocheck(p);
> +    return r.s;
> +#else
> +    qemu_build_not_reached();
> +#endif
> +}

Something that I remembered: Are we OK with this potentially barfing
if you try it on read-only memory? AIUI some compilers (clang,
gcc is thinking about it) will emit a cmpxchg or a load/store
exclusive loop inline for 128 bit atomic loads.

(eg https://godbolt.org/z/GaGKhT4f9 is not for the exact builtin
that qatomic_read__nocheck() boils down to but does show the
compiler will do this.)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]