From: Mark Brown <broonie@kernel.org>
To: Luis Machado <luis.machado@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Shuah Khan <shuah@kernel.org>,
Alan Hayward <alan.hayward@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 2/4] arm64/ptrace: Document extension of NT_ARM_TLS to cover TPIDR2_EL0
Date: Thu, 18 Aug 2022 13:52:31 +0100 [thread overview]
Message-ID: <Yv42D690DE6uLYT1@sirena.org.uk> (raw)
In-Reply-To: <4cf1c8d9-4aa8-dc1c-a568-69d86b706a60@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]
On Thu, Aug 18, 2022 at 10:17:11AM +0100, Luis Machado wrote:
> On 8/15/22 14:30, Mark Brown wrote:
> > +* The NT_ARM_TLS note will be extended to two registers, the second register
> > + will contain TPIDR2_EL0 on systems that support SME and will be read as
> > + zero with writes ignored otherwise.
> I wonder if we should document a bit more about the use of TPIDR2, its states, values and
> block format when TPIDR2 points to valid ZA state.
> Would that make sense?
That seems somewhat out of scope for the kernel, it's doesn't have any
idea about the use of TPIDR2 and I'm not sure we want to give anyone the
impression that it might try to do anything clever with it. From the
perspective of the kernel ABI this is simply another TPIDR that needs to
be context switched, I have heard some suggestions that the kernel
should try to do a spill to the TPIDR2 block allocated in user memory
directly but that feels like it's getting a bit more hairy than we want
and problematic for anyone doing off piste with regard to ABI.
Also note that the spec for TPIDR2 didn't get merged into the PCS yet so
it's not quite finalised.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-08-18 12:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 13:30 [PATCH v2 0/4] arm64/sme: ptrace support for TPIDR2_EL0 Mark Brown
2022-08-15 13:30 ` [PATCH v2 1/4] kselftest/arm64: Add test coverage for NT_ARM_TLS Mark Brown
2022-08-18 9:03 ` Luis Machado
2022-08-15 13:30 ` [PATCH v2 2/4] arm64/ptrace: Document extension of NT_ARM_TLS to cover TPIDR2_EL0 Mark Brown
2022-08-18 9:17 ` Luis Machado
2022-08-18 12:52 ` Mark Brown [this message]
2022-08-15 13:30 ` [PATCH v2 3/4] arm64/ptrace: Support access to TPIDR2_EL0 Mark Brown
2022-08-18 10:59 ` Luis Machado
2022-08-15 13:30 ` [PATCH v2 4/4] kselftest/arm64: Add coverage of TPIDR2_EL0 ptrace interface Mark Brown
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=Yv42D690DE6uLYT1@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alan.hayward@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luis.machado@arm.com \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.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