qemu-riscv
[Top][All Lists]
Advanced

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

Re: [PATCH v4 00/57] tcg: Improve atomicity support


From: Peter Maydell
Subject: Re: [PATCH v4 00/57] tcg: Improve atomicity support
Date: Fri, 5 May 2023 14:43:29 +0100

On Wed, 3 May 2023 at 08:10, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> v1: 
> https://lore.kernel.org/qemu-devel/20221118094754.242910-1-richard.henderson@linaro.org/
> v2: 
> https://lore.kernel.org/qemu-devel/20230216025739.1211680-1-richard.henderson@linaro.org/
> v3: 
> https://lore.kernel.org/qemu-devel/20230425193146.2106111-1-richard.henderson@linaro.org/
>
> Based-on: 20230503065729.1745843-1-richard.henderson@linaro.org
> ("[PATCH v4 00/54] tcg: Simplify calls to load/store helpers")
>
> The main objective here is to support Arm FEAT_LSE2, which says that any
> single memory access that does not cross a 16-byte boundary is atomic.
> This is the MO_ATOM_WITHIN16 control.
>
> While I'm touching all of this, a secondary objective is to handle the
> atomicity of the IBM machines.  Both Power and s390x treat misaligned
> accesses as atomic on the lsb of the pointer.  For instance, an 8-byte
> access at ptr % 8 == 4 will appear as two atomic 4-byte accesses, and
> ptr % 4 == 2 will appear as four 2-byte accesses.
> This is the MO_ATOM_SUBALIGN control.
>
> By default, acceses are atomic only if aligned, which is the current
> behaviour of the tcg code generator (mostly, anyway, there were bugs).
> This is the MO_ATOM_IFALIGN control.
>
> Further, one can say that a large memory access is really a set of
> contiguous smaller accesses, and we need not provide more atomicity
> than that (modulo MO_ATOM_WITHIN16).  This is the MO_ATMAX_* control.

I've reviewed as much of this series as I'm going to -- I left
a few patches for people who know more about ppc/s390 than me.

thanks
-- PMM



reply via email to

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