On Mon, 7 Sept 2026 at 11:12, BillXiang <[email protected]> wrote: > > On 9/4/2026 9:34 PM, Peter Xu wrote: > > On Tue, Sep 01, 2026 at 10:44:13AM +0800, BillXiang wrote: > >> On 8/24/2026 11:23 PM, Peter Xu wrote: > >>> On Mon, Aug 24, 2026 at 12:19:15PM +0800, BillXiang wrote: > >>>> Hi Richard, I've read your code in accel/tcg/ldst_atomicity.c.inc. Do > >>>> you think it would be better to make the load/store_atomic* public? > >>> > >>> They do not fit by default, as we need to still process unaligned cases? > >> > >> You mentioned the use of guest CPU context in [1]. However, what I meant > >> by load/store_atomic* is code like the following: > >> > >> static inline uint16_t load_atomic2(void *pv) > >> { > >> uint16_t *p = __builtin_assume_aligned(pv, 2); > >> return qatomic_read(p); > >> } > >> > >> static inline void store_atomic2(void *pv, uint16_t val) > >> { > >> uint16_t *p = __builtin_assume_aligned(pv, 2); > >> qatomic_set(p, val); > >> } > >> > >> I consider these to be generic atomic load/store primitives. > > > > __builtin_assume_aligned() tells the compiler the address is aligned. What > > if it is not? > > When using __builtin_assume_aligned, the compiler will generate > unaligned load/store instructions if the data is not aligned, rather > than emitting byte‑by‑byte code, which may cause errors on processors > that do not support unaligned accesses. That's what I mean: callers must > ensure @addr is naturally aligned to the access size.
Indeed. That's why the ldst_atomicity.c.inc code only calls them when it can guarantee the alignment, with fallback cases for when it isn't. Those are the lowest level internal functions in that code, and the higher level ones are things like load_atom_2() (which might call load_atomic2() if the address is 2-aligned, or lduw_he_p() if it's not but the caller said it doesn't care about getting a 2-byte-atomic load for an unaligned pointer, or a function to do an atomic 8-byte access and extract the 2 bytes we care about, or if all else fails falling back to "stop all QEMU threads and do a non-atomic read". The difficulty in generalizing that code for device use I suspect is whether the fallback cases remain the right thing to do. -- PMM
