On Thu, 2018-12-13 at 21:01 -0600, Richard Henderson wrote: > On 12/13/18 5:58 PM, Benjamin Herrenschmidt wrote: > > +#ifdef CONFIG_ATOMIC64 > > +/* This is meant to be used for atomic PTE updates under MT-TCG */ > > +uint32_t glue(address_space_cmpxchgq_notdirty, SUFFIX)(ARG1_DECL, > > + hwaddr addr, uint64_t old, uint64_t new, MemTxAttrs attrs, MemTxResult > > *result) > > +{ > > + uint8_t *ptr; > > + MemoryRegion *mr; > > + hwaddr l = 8; > > + hwaddr addr1; > > + MemTxResult r; > > + uint8_t dirty_log_mask; > > + > > + /* Must test result */ > > + assert(result); > > + > > + RCU_READ_LOCK(); > > + mr = TRANSLATE(addr, &addr1, &l, true, attrs); > > + if (l < 8 || !memory_access_is_direct(mr, true)) { > > + r = MEMTX_ERROR; > > + } else { > > + uint32_t orig = old; > > + > > + ptr = qemu_map_ram_ptr(mr->ram_block, addr1); > > + old = atomic_cmpxchg(ptr, orig, new); > > + > > I think you need atomic_cmpxchg__nocheck here. > > Failure would be with a 32-bit host that supports ATOMIC64. > E.g. i686.
I'm confused by this and the comments around the definition of ATOMIC_REG_SIZE :) So would we have CONFIG_ATOMIC64 in that case and if yes why if all the atomic_* end up barfing ? Or rather, why set CONFIG_ATOMIC64 if we ought not to use 64-bit atomics ? Also we should probably define ATOMIC_REG_SIZE to 8 for ppc64... Cheers Ben. > > r~