From: Nicholas Piggin <npiggin@gmail.com>
To: qemu-ppc@nongnu.org
Cc: Nicholas Piggin <npiggin@gmail.com>,
qemu-devel@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>
Subject: [RFC PATCH 0/3] real ll/sc emulation
Date: Tue, 20 Feb 2024 14:19:19 +1000 [thread overview]
Message-ID: <20240220041922.373029-1-npiggin@gmail.com> (raw)
I've been toying with how we might do a more faithful ll/sc emulation.
Our cmpxchg based one actually had problems on some firmware code we're
testing.
The using the dirty memory bitmap to detect stores coming from other
CPUs and invalidating active protection / reservations seems to be a
possibility. This passes some basic atomic and locking stress tests
with mttcg, and boots Linux.
Excuse some of the hacky / ugly / unfinished bits of code, I missed
getting into details of vfio, migration, and making it clean. Just
wanted to hear thoughts on the general idea at the moment.
The code doesn't seem to be _terribly_ tricky, but there are some
tricks around the store-conditional side of it where we have to
take a mutex, do the tlb lookup with possible recursion into the
code protected by that mutex, verify the protection is still active,
and then modify memory.
There is only a single lock now, but if that beomes a problem we
*might* be able to split it via physical address hash. But that
doesn't help uncontended performance or contention on the same
address, which are probably the two most important cases.
(I will submit the TCG TLB coherency fix patch separately, difficulty
at the moment is creating a test case for it that does not require
subsequent patches!)
Thanks,
Nick
Nicholas Piggin (3):
accel/tcg: Fix TCG TLB coherency race with physical dirty bit clearing
tcg: add a ll/sc protection facility
target/ppc: Implement reservation protection for larx/stcx
include/exec/cputlb.h | 7 ++
include/exec/exec-all.h | 1 -
include/exec/ram_addr.h | 42 ++++++-
include/exec/ramlist.h | 10 ++
include/hw/core/cpu.h | 5 +
target/ppc/cpu-param.h | 4 +
target/ppc/helper.h | 2 +
accel/stubs/tcg-stub.c | 4 -
accel/tcg/cputlb.c | 235 ++++++++++++++++++++++++++++++++++++---
hw/core/cpu-common.c | 5 +
hw/vfio/common.c | 2 +-
hw/virtio/vhost.c | 1 +
system/memory.c | 3 +
system/physmem.c | 7 ++
target/ppc/cpu_init.c | 4 +
target/ppc/mem_helper.c | 132 ++++++++++++++++++++++
target/ppc/translate.c | 128 +++++----------------
system/memory_ldst.c.inc | 3 +-
18 files changed, 467 insertions(+), 128 deletions(-)
--
2.42.0
next reply other threads:[~2024-02-20 4:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 4:19 Nicholas Piggin [this message]
2024-02-20 4:19 ` [RFC PATCH 1/3] accel/tcg: Fix TCG TLB coherency race with physical dirty bit clearing Nicholas Piggin
2024-02-20 4:19 ` [RFC PATCH 2/3] tcg: add a ll/sc protection facility Nicholas Piggin
2024-02-20 18:53 ` Richard Henderson
2024-02-20 4:19 ` [RFC PATCH 3/3] target/ppc: Implement reservation protection for larx/stcx Nicholas Piggin
2024-02-20 19:03 ` Richard Henderson
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=20240220041922.373029-1-npiggin@gmail.com \
--to=npiggin@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=richard.henderson@linaro.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).