| Message ID | 20220815133034.231718-3-broonie@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | f285da05c62a429f1978c5520cf069d483a7d9af |
| Headers | show |
| Series | arm64/sme: ptrace support for TPIDR2_EL0 | expand |
On 8/15/22 14:30, Mark Brown wrote: > In order to allow debuggers to discover lazily saved SME state we need > to provide access to TPIDR2_EL0, we will extend the existing NT_ARM_TLS > used for TPIDR to also include TPIDR2_EL0 as the second register in the > regset. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > Documentation/arm64/sme.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/arm64/sme.rst b/Documentation/arm64/sme.rst > index 937147f58cc5..16d2db4c2e2e 100644 > --- a/Documentation/arm64/sme.rst > +++ b/Documentation/arm64/sme.rst > @@ -331,6 +331,9 @@ The regset data starts with struct user_za_header, containing: > been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread > when the coredump was generated. > > +* 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. > > 9. System runtime configuration > -------------------------------- 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?
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.
diff --git a/Documentation/arm64/sme.rst b/Documentation/arm64/sme.rst index 937147f58cc5..16d2db4c2e2e 100644 --- a/Documentation/arm64/sme.rst +++ b/Documentation/arm64/sme.rst @@ -331,6 +331,9 @@ The regset data starts with struct user_za_header, containing: been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread when the coredump was generated. +* 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. 9. System runtime configuration --------------------------------
In order to allow debuggers to discover lazily saved SME state we need to provide access to TPIDR2_EL0, we will extend the existing NT_ARM_TLS used for TPIDR to also include TPIDR2_EL0 as the second register in the regset. Signed-off-by: Mark Brown <broonie@kernel.org> --- Documentation/arm64/sme.rst | 3 +++ 1 file changed, 3 insertions(+)