Feature request for enabling SCTLR_ELx.nAA

Feature request for enabling SCTLR_ELx.nAA

[Richard Henderson]

Hi guys,

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().

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.

Thanks,


r~

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Feature request for enabling SCTLR_ELx.nAA

[Catalin Marinas]

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

Re: Feature request for enabling SCTLR_ELx.nAA

[Richard Henderson]

On 2/23/23 02:15, Catalin Marinas wrote:
> 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.

Yes, my intended use is just the acquire/release.

As I read the Arm ARM pseudo-code for aarch64/functions/memory/Mem, the !aligned case 
devolves to a series of bytes, but with the same acctype, so each byte is AccType_ORDERED.

Which is just fine for my use case.


r~

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Feature request for enabling SCTLR_ELx.nAA

[Will Deacon]

On Thu, Feb 23, 2023 at 12:15:43PM +0000, Catalin Marinas wrote:
> 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.

I'd definitely want to see some numbers to justify the complexity of a new
prctl(), but otherwise it sounds fine as long as it's opt-in and cleared on
exec().

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel