From: Richard Henderson <richard.henderson@linaro.org>
To: qemu-devel@nongnu.org
Cc: alex.bennee@linaro.org, matheus.ferst@eldorado.org.br,
david@gibson.dropbear.id.au
Subject: [PATCH v2 0/1] accel/tcg: Fix #390 and other atomicity musings
Date: Wed, 16 Jun 2021 18:12:23 -0700 [thread overview]
Message-ID: <20210617011224.1602932-1-richard.henderson@linaro.org> (raw)
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
next reply other threads:[~2021-06-17 1:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 1:12 Richard Henderson [this message]
2021-06-17 1:12 ` [PATCH v2 1/1] accel/tcg: Probe the proper permissions for atomic ops Richard Henderson
2021-06-18 18:57 ` Matheus K. Ferst
2021-06-18 19:32 ` Richard Henderson
2021-06-21 13:20 ` Matheus K. Ferst
2021-06-21 13:21 ` Matheus K. Ferst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210617011224.1602932-1-richard.henderson@linaro.org \
--to=richard.henderson@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=david@gibson.dropbear.id.au \
--cc=matheus.ferst@eldorado.org.br \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).