This fixes some bugs reported against 128-bit atomic operations. Just a note that the ppc insns that uses this, LQ and STQ, do not require atomic operations if the address is unaligned, or if the address does not resolve to ram. So for some things we are working harder than required.
I've also had a good read of Power's atomicity requirements, for all instructions. It requires that the lsb of the address control the minimum atomicity. E.g. for (addr % size) == 2, each 2-byte component must be atomic. Which is certainly not what we're doing at the bottom of our memory model at present. I've also been reading up on Arm's FEAT_LSE2, which is mandatory for v8.4. This vastly strengthens the single-copy atomicity requirements for the whole system. Strikingly, any access that does not cross a 16-byte boundary -- aligned or unaligned -- is now single-copy atomic. In both cases, I would imagine that we should only allow the softmmu fast path for aligned accesses. That's single-copy atomic on all hosts. But then we need different handling for each platform at the bottom of cputlb... Suggestions on ways to approach this that aren't overwhelmingly ugly? r~ Richard Henderson (1): accel/tcg: Probe the proper permissions for atomic ops accel/tcg/atomic_template.h | 24 +++++----- accel/tcg/cputlb.c | 95 ++++++++++++++++++++++++++----------- accel/tcg/user-exec.c | 8 ++-- 3 files changed, 83 insertions(+), 44 deletions(-) -- 2.25.1
