On Fri, 23 Feb 2024 at 10:02, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Thu, 22 Feb 2024 at 21:21, Richard Henderson > <richard.hender...@linaro.org> wrote: > > > > On 2/19/24 06:12, Jonathan Cameron wrote: > > > I'm far from confident this handling here is correct. Hence > > > RFC. In particular not sure on what locks I should hold for this > > > to be even moderately safe. > > > > > > The function already appears to be inconsistent in what it returns > > > as the CONFIG_ATOMIC64 block returns the endian converted 'eventual' > > > value of the cmpxchg whereas the TCG_OVERSIZED_GUEST case returns > > > the previous value. > > I think this is a bug in the TCG_OVERSIZED_GUEST handling, > which we've never noticed because you only see that case > on a 32-bit host.
Having looked through the code and talked to Richard on IRC, I think that the TCG_OVERSIZED_GUEST handling is correct. The return value of qatomic_cmpxchg__nocheck() is the value that was in memory before the cmpxchg. So the TCG_OVERSIZED_GUEST code's semantics are the same as the normal path. (The comment on qatomic_cmpxchg__nocheck() that describes this as the "eventual value" is rather confusing so we should improve that.) thanks -- PMM