From: Catalin Marinas <catalin.marinas@arm.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
"Alex Bennée" <alex.bennee@linaro.org>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>
Subject: Re: Feature request for enabling SCTLR_ELx.nAA
Date: Thu, 23 Feb 2023 12:15:43 +0000 [thread overview]
Message-ID: <Y/dY7x+s9AXHyG0X@arm.com> (raw)
In-Reply-To: <d8a4334a-cbb0-77bc-6f1b-9563e55321fc@linaro.org>
On Wed, Feb 22, 2023 at 01:17:55PM -1000, Richard Henderson wrote:
> It would be helpful to have a prctl for enabling nAA. Since we already have
> task->thread.sctlr_user, it would seem that this would not require any
> additional overhead during __switch_to().
This shouldn't be difficult to add.
> My use case is the QEMU JIT, and being able to make use of LDAR/STLR instead
> of explicit DBM in some cases. At the moment, I can only make this
> replacement when the address is provably aligned, which is tricky to do with
> the time budget of a JIT, so the replacement rarely triggers. This ought to
> make a difference when emulating strongly ordered guests like x86.
It looks like in 4.17 (commit 7206dc93a58f, "arm64: Expose Arm v8.4
features") we exposed the LSE2 features as HWCAP_USCAT (unaligned
single-copy atomicity) but that still restricts LDAR/STLR to a 16-byte
boundary as there is no control for SCTLR_EL1.nAA.
Given that allowing unaligned accesses could break atomicity, I wouldn't
set this bit to 1 permanently, it helps catching tricky software bugs.
So a prctl() makes more sense. If your intended use is just preserving
the acquire/release semantics, I don't think these are affected by the
atomicity rules even if they go across a 16-byte boundary.
Adding Will and Mark for their view on this.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-02-23 12:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 23:17 Feature request for enabling SCTLR_ELx.nAA Richard Henderson
2023-02-23 12:15 ` Catalin Marinas [this message]
2023-02-23 15:36 ` Richard Henderson
2023-02-24 17:09 ` Will Deacon
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=Y/dY7x+s9AXHyG0X@arm.com \
--to=catalin.marinas@arm.com \
--cc=alex.bennee@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=richard.henderson@linaro.org \
--cc=will@kernel.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).