On 8/22/2026 1:32 AM, Richard Henderson wrote: > On 8/21/26 03:25, Peter Maydell wrote: >> I'm tempted to suggest some kind of "if pointer is aligned take >> aligned path, otherwise take slow path" either here or actually >> in lduw_le_p(), but maybe that's a bad idea. Richard ? >> >> (I have a suspicion that other places than this one will assume >> that an aligned ldl_he_p() is not going to tear.) > I agree -- I expect most everything assumes ldl_he_p won't tear for > aligned accesses.
Hi Peter, I noticed that in your commit [1], you have pointed out that ld*_he_p() and st*_he_p() is not atomic especially for vring_avail_idx. This suggests it’s time to finally implement the atomic functions. And I think we should provide explicit atomic operations, similar to those in CPU instruction sets, rather than a single all‑purpose function cluttered with conditional branches — and it should be the caller’s responsibility to decide whether to use them. > > This kinda begs the question of what atomicity the caller expects. It's > not implausible that an x86 path expects even unaligned accesses not > crossing a cacheline to be atomic, since that's been a thing since > 1995. I expect both IBM architectures similarly expect atomicity by > alignment, since that's been a thing for s390 since yonks and Power has > the same language. > > We have a bunch of code in accel/tcg/ldst_atomicity.c.inc that can > handle this, we'd just need to provide it with the correct inputs. And > I assume we'd still like to inline the single access on appropriate hosts. > > > r~ 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? -- Bill Xiang [1] https://lore.kernel.org/qemu-devel/[email protected]/#r
