* [PATCH V6 0/9] Add new powerpc specific ELF core notes
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch series adds five new ELF core note sections which can be
used with existing ptrace request PTRACE_GETREGSET-SETREGSET for accessing
various transactional memory and miscellaneous debug register sets on powerpc
platform.
Previous versions:
==================
RFC: https://lkml.org/lkml/2014/4/1/292
V1: https://lkml.org/lkml/2014/4/2/43
V2: https://lkml.org/lkml/2014/5/5/88
V3: https://lkml.org/lkml/2014/5/23/486
V4: https://lkml.org/lkml/2014/11/11/6
V5: https://lkml.org/lkml/2014/11/25/134
Changes in V6:
--------------
- Added two git ignore patches for powerpc selftests
- Re-formatted all in-code function definitions in kernel-doc format
Changes in V5:
--------------
- Changed flush_tmregs_to_thread, so not to take into account self tracing
- Dropped the 3rd patch in the series which had merged two functions
- Fixed one build problem for the misc debug register patch
- Accommodated almost all the review comments from Suka on the 6th patch
- Minor changes to the self test program
- Changed commit messages for some of the patches
Changes in V4:
--------------
- Added one test program into the powerpc selftest bucket in this regard
- Split the 2nd patch in the previous series into four different patches
- Accommodated most of the review comments on the previous patch series
- Added a patch to merge functions __switch_to_tm and tm_reclaim_task
Changes in V3:
--------------
- Added two new error paths in every TM related get/set functions when regset
support is not present on the system (ENODEV) or when the process does not
have any transaction active (ENODATA) in the context
- Installed the active hooks for all the newly added regset core note types
Changes in V2:
--------------
- Removed all the power specific ptrace requests corresponding to new NT_PPC_*
elf core note types. Now all the register sets can be accessed from ptrace
through PTRACE_GETREGSET/PTRACE_SETREGSET using the individual NT_PPC* core
note type instead
- Fixed couple of attribute values for REGSET_TM_CGPR register set
- Renamed flush_tmreg_to_thread as flush_tmregs_to_thread
- Fixed 32 bit checkpointed GPR support
- Changed commit messages accordingly
Test Result
-----------
The patch series has been verified both in 32 bit and 64 bit compiled test
program. Test result for the selftest test (64 bit compiled) can be found here.
test: tm_ptrace
tags: git_version:v3.18-rc6-8-ge2aa4ce
===Testing TM based PTRACE Interface===
Testing TM specific SPR:
TFHAR: 10001098
TEXASR: de0000018c000001
TFIAR: c000000000041858
TM ORIG_MSR: 800000050000f032
TM CH DSCR: a (PASSED)
TM CH TAR: 14 (PASSED)
TM CH PPR: 8000000000000 (PASSED)
Testing TM checkpointed GPR:
TM CH NIP: 10001098
TM CH LINK: 10000ea0
TM CH CCR: 24000422
TM CH GPR[0]: 0 (PASSED)
TM CH GPR[1]: 1 (PASSED)
TM CH GPR[2]: 2 (PASSED)
TM CH GPR[3]: 3 (PASSED)
TM CH GPR[4]: 4 (PASSED)
TM CH GPR[5]: 5 (PASSED)
TM CH GPR[6]: 6 (PASSED)
TM CH GPR[7]: 7 (PASSED)
TM CH GPR[8]: 8 (PASSED)
TM CH GPR[9]: 9 (PASSED)
TM CH GPR[10]: a (PASSED)
TM CH GPR[11]: b (PASSED)
TM CH GPR[12]: c (PASSED)
TM CH GPR[13]: d (PASSED)
TM CH GPR[14]: e (PASSED)
TM CH GPR[15]: f (PASSED)
TM CH GPR[16]: 0 (PASSED)
TM CH GPR[17]: 1 (PASSED)
TM CH GPR[18]: 2 (PASSED)
TM CH GPR[19]: 3 (PASSED)
TM CH GPR[20]: 4 (PASSED)
TM CH GPR[21]: 5 (PASSED)
TM CH GPR[22]: 6 (PASSED)
TM CH GPR[23]: 7 (PASSED)
TM CH GPR[24]: 8 (PASSED)
TM CH GPR[25]: 9 (PASSED)
TM CH GPR[26]: a (PASSED)
TM CH GPR[27]: b (PASSED)
TM CH GPR[28]: c (PASSED)
TM CH GPR[29]: d (PASSED)
TM CH GPR[30]: e (PASSED)
TM CH GPR[31]: f (PASSED)
Testing TM checkpointed FPR:
TM CH FPSCR: 0
TM CH FPR[0]: 0 (PASSED)
TM CH FPR[1]: 1 (PASSED)
TM CH FPR[2]: 2 (PASSED)
TM CH FPR[3]: 3 (PASSED)
TM CH FPR[4]: 4 (PASSED)
TM CH FPR[5]: 5 (PASSED)
TM CH FPR[6]: 6 (PASSED)
TM CH FPR[7]: 7 (PASSED)
TM CH FPR[8]: 8 (PASSED)
TM CH FPR[9]: 9 (PASSED)
TM CH FPR[10]: a (PASSED)
TM CH FPR[11]: b (PASSED)
TM CH FPR[12]: c (PASSED)
TM CH FPR[13]: d (PASSED)
TM CH FPR[14]: e (PASSED)
TM CH FPR[15]: f (PASSED)
TM CH FPR[16]: 0 (PASSED)
TM CH FPR[17]: 1 (PASSED)
TM CH FPR[18]: 2 (PASSED)
TM CH FPR[19]: 3 (PASSED)
TM CH FPR[20]: 4 (PASSED)
TM CH FPR[21]: 5 (PASSED)
TM CH FPR[22]: 6 (PASSED)
TM CH FPR[23]: 7 (PASSED)
TM CH FPR[24]: 8 (PASSED)
TM CH FPR[25]: 9 (PASSED)
TM CH FPR[26]: a (PASSED)
TM CH FPR[27]: b (PASSED)
TM CH FPR[28]: c (PASSED)
TM CH FPR[29]: d (PASSED)
TM CH FPR[30]: e (PASSED)
TM CH FPR[31]: f (PASSED)
Testing TM running GPR:
TM RN NIP: 100011b0
TM RN LINK: 10000ea0
TM RN CCR: 4000422
TM RN GPR[0]: f (PASSED)
TM RN GPR[1]: e (PASSED)
TM RN GPR[2]: d (PASSED)
TM RN GPR[3]: c (PASSED)
TM RN GPR[4]: b (PASSED)
TM RN GPR[5]: a (PASSED)
TM RN GPR[6]: 9 (PASSED)
TM RN GPR[7]: 8 (PASSED)
TM RN GPR[8]: 7 (PASSED)
TM RN GPR[9]: 6 (PASSED)
TM RN GPR[10]: 5 (PASSED)
TM RN GPR[11]: 4 (PASSED)
TM RN GPR[12]: 3 (PASSED)
TM RN GPR[13]: 2 (PASSED)
TM RN GPR[14]: 1 (PASSED)
TM RN GPR[15]: 0 (PASSED)
TM RN GPR[16]: f (PASSED)
TM RN GPR[17]: e (PASSED)
TM RN GPR[18]: d (PASSED)
TM RN GPR[19]: c (PASSED)
TM RN GPR[20]: b (PASSED)
TM RN GPR[21]: a (PASSED)
TM RN GPR[22]: 9 (PASSED)
TM RN GPR[23]: 8 (PASSED)
TM RN GPR[24]: 7 (PASSED)
TM RN GPR[25]: 6 (PASSED)
TM RN GPR[26]: 5 (PASSED)
TM RN GPR[27]: 4 (PASSED)
TM RN GPR[28]: 3 (PASSED)
TM RN GPR[29]: 2 (PASSED)
TM RN GPR[30]: 1 (PASSED)
TM RN GPR[31]: 0 (PASSED)
Testing TM running FPR:
TM RN FPSCR: 0
TM RN FPR[0]: f (PASSED)
TM RN FPR[1]: e (PASSED)
TM RN FPR[2]: d (PASSED)
TM RN FPR[3]: c (PASSED)
TM RN FPR[4]: b (PASSED)
TM RN FPR[5]: a (PASSED)
TM RN FPR[6]: 9 (PASSED)
TM RN FPR[7]: 8 (PASSED)
TM RN FPR[8]: 7 (PASSED)
TM RN FPR[9]: 6 (PASSED)
TM RN FPR[10]: 5 (PASSED)
TM RN FPR[11]: 4 (PASSED)
TM RN FPR[12]: 3 (PASSED)
TM RN FPR[13]: 2 (PASSED)
TM RN FPR[14]: 1 (PASSED)
TM RN FPR[15]: 0 (PASSED)
TM RN FPR[16]: f (PASSED)
TM RN FPR[17]: e (PASSED)
TM RN FPR[18]: d (PASSED)
TM RN FPR[19]: c (PASSED)
TM RN FPR[20]: b (PASSED)
TM RN FPR[21]: a (PASSED)
TM RN FPR[22]: 9 (PASSED)
TM RN FPR[23]: 8 (PASSED)
TM RN FPR[24]: 7 (PASSED)
TM RN FPR[25]: 6 (PASSED)
TM RN FPR[26]: 5 (PASSED)
TM RN FPR[27]: 4 (PASSED)
TM RN FPR[28]: 3 (PASSED)
TM RN FPR[29]: 2 (PASSED)
TM RN FPR[30]: 1 (PASSED)
TM RN FPR[31]: 0 (PASSED)
Testing TM running MISC debug registers:
TM RN DSCR: 32 (PASSED)
TM RN TAR: 3c (PASSED)
TM RN PPR: 4000000000000 (PASSED)
success: tm_ptrace
Anshuman Khandual (9):
elf: Add new powerpc specifc core note sections
powerpc, process: Add the function flush_tmregs_to_thread
powerpc, ptrace: Enable fpr_(get/set) for transactional memory
powerpc, ptrace: Enable vr_(get/set) for transactional memory
powerpc, ptrace: Enable support for transactional memory register sets
powerpc, ptrace: Enable support for miscellaneous debug registers
selftests, powerpc: Add test case for TM related ptrace interface
selftests, powerpc: Make GIT ignore all binaries related to TM
selftests: Make GIT ignore all binaries in powerpc test suite
arch/powerpc/include/asm/switch_to.h | 8 +
arch/powerpc/include/uapi/asm/elf.h | 3 +
arch/powerpc/kernel/process.c | 20 +
arch/powerpc/kernel/ptrace.c | 1059 +++++++++++++++++++-
include/uapi/linux/elf.h | 5 +
.../testing/selftests/powerpc/copyloops/.gitignore | 4 +
tools/testing/selftests/powerpc/mm/.gitignore | 1 +
tools/testing/selftests/powerpc/pmu/.gitignore | 3 +
tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 +
.../selftests/powerpc/primitives/.gitignore | 1 +
tools/testing/selftests/powerpc/tm/.gitignore | 2 +
tools/testing/selftests/powerpc/tm/Makefile | 2 +-
tools/testing/selftests/powerpc/tm/tm-ptrace.c | 542 ++++++++++
13 files changed, 1647 insertions(+), 25 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
create mode 100644 tools/testing/selftests/powerpc/tm/.gitignore
create mode 100644 tools/testing/selftests/powerpc/tm/tm-ptrace.c
--
1.9.3
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH V6 0/9] Add new powerpc specific ELF core notes
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch series adds five new ELF core note sections which can be
used with existing ptrace request PTRACE_GETREGSET-SETREGSET for accessing
various transactional memory and miscellaneous debug register sets on powerpc
platform.
Previous versions:
==================
RFC: https://lkml.org/lkml/2014/4/1/292
V1: https://lkml.org/lkml/2014/4/2/43
V2: https://lkml.org/lkml/2014/5/5/88
V3: https://lkml.org/lkml/2014/5/23/486
V4: https://lkml.org/lkml/2014/11/11/6
V5: https://lkml.org/lkml/2014/11/25/134
Changes in V6:
--------------
- Added two git ignore patches for powerpc selftests
- Re-formatted all in-code function definitions in kernel-doc format
Changes in V5:
--------------
- Changed flush_tmregs_to_thread, so not to take into account self tracing
- Dropped the 3rd patch in the series which had merged two functions
- Fixed one build problem for the misc debug register patch
- Accommodated almost all the review comments from Suka on the 6th patch
- Minor changes to the self test program
- Changed commit messages for some of the patches
Changes in V4:
--------------
- Added one test program into the powerpc selftest bucket in this regard
- Split the 2nd patch in the previous series into four different patches
- Accommodated most of the review comments on the previous patch series
- Added a patch to merge functions __switch_to_tm and tm_reclaim_task
Changes in V3:
--------------
- Added two new error paths in every TM related get/set functions when regset
support is not present on the system (ENODEV) or when the process does not
have any transaction active (ENODATA) in the context
- Installed the active hooks for all the newly added regset core note types
Changes in V2:
--------------
- Removed all the power specific ptrace requests corresponding to new NT_PPC_*
elf core note types. Now all the register sets can be accessed from ptrace
through PTRACE_GETREGSET/PTRACE_SETREGSET using the individual NT_PPC* core
note type instead
- Fixed couple of attribute values for REGSET_TM_CGPR register set
- Renamed flush_tmreg_to_thread as flush_tmregs_to_thread
- Fixed 32 bit checkpointed GPR support
- Changed commit messages accordingly
Test Result
-----------
The patch series has been verified both in 32 bit and 64 bit compiled test
program. Test result for the selftest test (64 bit compiled) can be found here.
test: tm_ptrace
tags: git_version:v3.18-rc6-8-ge2aa4ce
===Testing TM based PTRACE Interface===
Testing TM specific SPR:
TFHAR: 10001098
TEXASR: de0000018c000001
TFIAR: c000000000041858
TM ORIG_MSR: 800000050000f032
TM CH DSCR: a (PASSED)
TM CH TAR: 14 (PASSED)
TM CH PPR: 8000000000000 (PASSED)
Testing TM checkpointed GPR:
TM CH NIP: 10001098
TM CH LINK: 10000ea0
TM CH CCR: 24000422
TM CH GPR[0]: 0 (PASSED)
TM CH GPR[1]: 1 (PASSED)
TM CH GPR[2]: 2 (PASSED)
TM CH GPR[3]: 3 (PASSED)
TM CH GPR[4]: 4 (PASSED)
TM CH GPR[5]: 5 (PASSED)
TM CH GPR[6]: 6 (PASSED)
TM CH GPR[7]: 7 (PASSED)
TM CH GPR[8]: 8 (PASSED)
TM CH GPR[9]: 9 (PASSED)
TM CH GPR[10]: a (PASSED)
TM CH GPR[11]: b (PASSED)
TM CH GPR[12]: c (PASSED)
TM CH GPR[13]: d (PASSED)
TM CH GPR[14]: e (PASSED)
TM CH GPR[15]: f (PASSED)
TM CH GPR[16]: 0 (PASSED)
TM CH GPR[17]: 1 (PASSED)
TM CH GPR[18]: 2 (PASSED)
TM CH GPR[19]: 3 (PASSED)
TM CH GPR[20]: 4 (PASSED)
TM CH GPR[21]: 5 (PASSED)
TM CH GPR[22]: 6 (PASSED)
TM CH GPR[23]: 7 (PASSED)
TM CH GPR[24]: 8 (PASSED)
TM CH GPR[25]: 9 (PASSED)
TM CH GPR[26]: a (PASSED)
TM CH GPR[27]: b (PASSED)
TM CH GPR[28]: c (PASSED)
TM CH GPR[29]: d (PASSED)
TM CH GPR[30]: e (PASSED)
TM CH GPR[31]: f (PASSED)
Testing TM checkpointed FPR:
TM CH FPSCR: 0
TM CH FPR[0]: 0 (PASSED)
TM CH FPR[1]: 1 (PASSED)
TM CH FPR[2]: 2 (PASSED)
TM CH FPR[3]: 3 (PASSED)
TM CH FPR[4]: 4 (PASSED)
TM CH FPR[5]: 5 (PASSED)
TM CH FPR[6]: 6 (PASSED)
TM CH FPR[7]: 7 (PASSED)
TM CH FPR[8]: 8 (PASSED)
TM CH FPR[9]: 9 (PASSED)
TM CH FPR[10]: a (PASSED)
TM CH FPR[11]: b (PASSED)
TM CH FPR[12]: c (PASSED)
TM CH FPR[13]: d (PASSED)
TM CH FPR[14]: e (PASSED)
TM CH FPR[15]: f (PASSED)
TM CH FPR[16]: 0 (PASSED)
TM CH FPR[17]: 1 (PASSED)
TM CH FPR[18]: 2 (PASSED)
TM CH FPR[19]: 3 (PASSED)
TM CH FPR[20]: 4 (PASSED)
TM CH FPR[21]: 5 (PASSED)
TM CH FPR[22]: 6 (PASSED)
TM CH FPR[23]: 7 (PASSED)
TM CH FPR[24]: 8 (PASSED)
TM CH FPR[25]: 9 (PASSED)
TM CH FPR[26]: a (PASSED)
TM CH FPR[27]: b (PASSED)
TM CH FPR[28]: c (PASSED)
TM CH FPR[29]: d (PASSED)
TM CH FPR[30]: e (PASSED)
TM CH FPR[31]: f (PASSED)
Testing TM running GPR:
TM RN NIP: 100011b0
TM RN LINK: 10000ea0
TM RN CCR: 4000422
TM RN GPR[0]: f (PASSED)
TM RN GPR[1]: e (PASSED)
TM RN GPR[2]: d (PASSED)
TM RN GPR[3]: c (PASSED)
TM RN GPR[4]: b (PASSED)
TM RN GPR[5]: a (PASSED)
TM RN GPR[6]: 9 (PASSED)
TM RN GPR[7]: 8 (PASSED)
TM RN GPR[8]: 7 (PASSED)
TM RN GPR[9]: 6 (PASSED)
TM RN GPR[10]: 5 (PASSED)
TM RN GPR[11]: 4 (PASSED)
TM RN GPR[12]: 3 (PASSED)
TM RN GPR[13]: 2 (PASSED)
TM RN GPR[14]: 1 (PASSED)
TM RN GPR[15]: 0 (PASSED)
TM RN GPR[16]: f (PASSED)
TM RN GPR[17]: e (PASSED)
TM RN GPR[18]: d (PASSED)
TM RN GPR[19]: c (PASSED)
TM RN GPR[20]: b (PASSED)
TM RN GPR[21]: a (PASSED)
TM RN GPR[22]: 9 (PASSED)
TM RN GPR[23]: 8 (PASSED)
TM RN GPR[24]: 7 (PASSED)
TM RN GPR[25]: 6 (PASSED)
TM RN GPR[26]: 5 (PASSED)
TM RN GPR[27]: 4 (PASSED)
TM RN GPR[28]: 3 (PASSED)
TM RN GPR[29]: 2 (PASSED)
TM RN GPR[30]: 1 (PASSED)
TM RN GPR[31]: 0 (PASSED)
Testing TM running FPR:
TM RN FPSCR: 0
TM RN FPR[0]: f (PASSED)
TM RN FPR[1]: e (PASSED)
TM RN FPR[2]: d (PASSED)
TM RN FPR[3]: c (PASSED)
TM RN FPR[4]: b (PASSED)
TM RN FPR[5]: a (PASSED)
TM RN FPR[6]: 9 (PASSED)
TM RN FPR[7]: 8 (PASSED)
TM RN FPR[8]: 7 (PASSED)
TM RN FPR[9]: 6 (PASSED)
TM RN FPR[10]: 5 (PASSED)
TM RN FPR[11]: 4 (PASSED)
TM RN FPR[12]: 3 (PASSED)
TM RN FPR[13]: 2 (PASSED)
TM RN FPR[14]: 1 (PASSED)
TM RN FPR[15]: 0 (PASSED)
TM RN FPR[16]: f (PASSED)
TM RN FPR[17]: e (PASSED)
TM RN FPR[18]: d (PASSED)
TM RN FPR[19]: c (PASSED)
TM RN FPR[20]: b (PASSED)
TM RN FPR[21]: a (PASSED)
TM RN FPR[22]: 9 (PASSED)
TM RN FPR[23]: 8 (PASSED)
TM RN FPR[24]: 7 (PASSED)
TM RN FPR[25]: 6 (PASSED)
TM RN FPR[26]: 5 (PASSED)
TM RN FPR[27]: 4 (PASSED)
TM RN FPR[28]: 3 (PASSED)
TM RN FPR[29]: 2 (PASSED)
TM RN FPR[30]: 1 (PASSED)
TM RN FPR[31]: 0 (PASSED)
Testing TM running MISC debug registers:
TM RN DSCR: 32 (PASSED)
TM RN TAR: 3c (PASSED)
TM RN PPR: 4000000000000 (PASSED)
success: tm_ptrace
Anshuman Khandual (9):
elf: Add new powerpc specifc core note sections
powerpc, process: Add the function flush_tmregs_to_thread
powerpc, ptrace: Enable fpr_(get/set) for transactional memory
powerpc, ptrace: Enable vr_(get/set) for transactional memory
powerpc, ptrace: Enable support for transactional memory register sets
powerpc, ptrace: Enable support for miscellaneous debug registers
selftests, powerpc: Add test case for TM related ptrace interface
selftests, powerpc: Make GIT ignore all binaries related to TM
selftests: Make GIT ignore all binaries in powerpc test suite
arch/powerpc/include/asm/switch_to.h | 8 +
arch/powerpc/include/uapi/asm/elf.h | 3 +
arch/powerpc/kernel/process.c | 20 +
arch/powerpc/kernel/ptrace.c | 1059 +++++++++++++++++++-
include/uapi/linux/elf.h | 5 +
.../testing/selftests/powerpc/copyloops/.gitignore | 4 +
tools/testing/selftests/powerpc/mm/.gitignore | 1 +
tools/testing/selftests/powerpc/pmu/.gitignore | 3 +
tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 +
.../selftests/powerpc/primitives/.gitignore | 1 +
tools/testing/selftests/powerpc/tm/.gitignore | 2 +
tools/testing/selftests/powerpc/tm/Makefile | 2 +-
tools/testing/selftests/powerpc/tm/tm-ptrace.c | 542 ++++++++++
13 files changed, 1647 insertions(+), 25 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
create mode 100644 tools/testing/selftests/powerpc/tm/.gitignore
create mode 100644 tools/testing/selftests/powerpc/tm/tm-ptrace.c
--
1.9.3
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH V6 1/9] elf: Add new powerpc specifc core note sections
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch adds four new ELF core note sections for powerpc
transactional memory and one new ELF core note section for
powerpc general miscellaneous debug registers. These addition
of new ELF core note sections extends the existing ELF ABI
without affecting it in any manner.
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
include/uapi/linux/elf.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index ea9bf25..2260fc0 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -379,6 +379,11 @@ typedef struct elf64_shdr {
#define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
#define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
#define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
+#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
+#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
+#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
+#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
+#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
#define NT_386_TLS 0x200 /* i386 TLS slots (struct user_desc) */
#define NT_386_IOPERM 0x201 /* x86 io permission bitmap (1=deny) */
#define NT_X86_XSTATE 0x202 /* x86 extended state using xsave */
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 1/9] elf: Add new powerpc specifc core note sections
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch adds four new ELF core note sections for powerpc
transactional memory and one new ELF core note section for
powerpc general miscellaneous debug registers. These addition
of new ELF core note sections extends the existing ELF ABI
without affecting it in any manner.
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
include/uapi/linux/elf.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index ea9bf25..2260fc0 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -379,6 +379,11 @@ typedef struct elf64_shdr {
#define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
#define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
#define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
+#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
+#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
+#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
+#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
+#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
#define NT_386_TLS 0x200 /* i386 TLS slots (struct user_desc) */
#define NT_386_IOPERM 0x201 /* x86 io permission bitmap (1=deny) */
#define NT_X86_XSTATE 0x202 /* x86 extended state using xsave */
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 2/9] powerpc, process: Add the function flush_tmregs_to_thread
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch creates a function flush_tmregs_to_thread which
will then be used by subsequent patches in this series. The
function checks for self tracing ptrace interface attempts
while in the TM context and logs appropriate warning message.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/switch_to.h | 8 ++++++++
arch/powerpc/kernel/process.c | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+)
diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
index 58abeda..23752a9 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -82,6 +82,14 @@ static inline void flush_spe_to_thread(struct task_struct *t)
}
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+extern void flush_tmregs_to_thread(struct task_struct *);
+#else
+static inline void flush_tmregs_to_thread(struct task_struct *t)
+{
+}
+#endif
+
static inline void clear_task_ebb(struct task_struct *t)
{
#ifdef CONFIG_PPC_BOOK3S_64
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 923cd2d..0013f24 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -745,6 +745,26 @@ void restore_tm_state(struct pt_regs *regs)
#define __switch_to_tm(prev)
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+void flush_tmregs_to_thread(struct task_struct *tsk)
+{
+ /*
+ * Process self tracing is not yet supported through
+ * ptrace interface. Ptrace generic code should have
+ * prevented this from happening in the first place.
+ * Warn once here with the message, if some how it
+ * is attempted.
+ */
+ WARN_ONCE(tsk == current,
+ "Not expecting ptrace on self: TM regs may be incorrect\n");
+
+ /*
+ * If task is not current, it should have been flushed
+ * already to it's thread_struct during __switch_to().
+ */
+}
+#endif
+
struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *new)
{
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 2/9] powerpc, process: Add the function flush_tmregs_to_thread
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch creates a function flush_tmregs_to_thread which
will then be used by subsequent patches in this series. The
function checks for self tracing ptrace interface attempts
while in the TM context and logs appropriate warning message.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/switch_to.h | 8 ++++++++
arch/powerpc/kernel/process.c | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+)
diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
index 58abeda..23752a9 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -82,6 +82,14 @@ static inline void flush_spe_to_thread(struct task_struct *t)
}
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+extern void flush_tmregs_to_thread(struct task_struct *);
+#else
+static inline void flush_tmregs_to_thread(struct task_struct *t)
+{
+}
+#endif
+
static inline void clear_task_ebb(struct task_struct *t)
{
#ifdef CONFIG_PPC_BOOK3S_64
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 923cd2d..0013f24 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -745,6 +745,26 @@ void restore_tm_state(struct pt_regs *regs)
#define __switch_to_tm(prev)
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+void flush_tmregs_to_thread(struct task_struct *tsk)
+{
+ /*
+ * Process self tracing is not yet supported through
+ * ptrace interface. Ptrace generic code should have
+ * prevented this from happening in the first place.
+ * Warn once here with the message, if some how it
+ * is attempted.
+ */
+ WARN_ONCE(tsk == current,
+ "Not expecting ptrace on self: TM regs may be incorrect\n");
+
+ /*
+ * If task is not current, it should have been flushed
+ * already to it's thread_struct during __switch_to().
+ */
+}
+#endif
+
struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *new)
{
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 3/9] powerpc, ptrace: Enable fpr_(get/set) for transactional memory
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch enables the fpr_get which gets the running value of all
the FPR registers and the fpr_set which sets the running value of
of all the FPR registers to accommodate in transaction ptrace
interface based requests.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/kernel/ptrace.c | 110 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 104 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index f21897b..2de3b2c 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -357,6 +357,36 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
return ret;
}
+
+/**
+ * fpr_get - get FPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * When the transaction is active, 'transact_fp' holds the current running
+ * value of all FPR registers and 'fp_state' holds the last checkpointed
+ * value of all FPR registers for the current transaction. When transaction
+ * is not active 'fp_state' holds the current running state of all the FPR
+ * registers. So this function which returns the current running values of
+ * all the FPR registers, needs to know whether any transaction is active
+ * or not. The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ * };
+ *
+ * There are two config options CONFIG_VSX and CONFIG_PPC_TRANSACTIONAL_MEM
+ * which determines the final code in this function. All the combinations of
+ * these two config options are possible except the one below as transactional
+ * memory config pulls in CONFIG_VSX automatically.
+ *
+ * !defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ */
static int fpr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
@@ -367,22 +397,68 @@ static int fpr_get(struct task_struct *target, const struct user_regset *regset,
#endif
flush_fp_to_thread(target);
-#ifdef CONFIG_VSX
+#if defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ /* copy to local buffer then write that out */
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ for (i = 0; i < 32 ; i++)
+ buf[i] = target->thread.TS_TRANS_FPR(i);
+ buf[32] = target->thread.transact_fp.fpscr;
+ } else {
+ for (i = 0; i < 32 ; i++)
+ buf[i] = target->thread.TS_FPR(i);
+ buf[32] = target->thread.fp_state.fpscr;
+ }
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+#endif
+
+#if defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
/* copy to local buffer then write that out */
for (i = 0; i < 32 ; i++)
buf[i] = target->thread.TS_FPR(i);
buf[32] = target->thread.fp_state.fpscr;
return user_regset_copyout(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+#endif
-#else
+
+#if !defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
offsetof(struct thread_fp_state, fpr[32][0]));
-
return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
#endif
}
+/**
+ * fpr_set - set FPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * When the transaction is active, 'transact_fp' holds the current running
+ * value of all FPR registers and 'fp_state' holds the last checkpointed
+ * value of all FPR registers for the current transaction. When transaction
+ * is not active 'fp_state' holds the current running state of all the FPR
+ * registers. So this function which setss the current running values of
+ * all the FPR registers, needs to know whether any transaction is active
+ * or not. The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ * };
+ *
+ * There are two config options CONFIG_VSX and CONFIG_PPC_TRANSACTIONAL_MEM
+ * which determines the final code in this function. All the combinations of
+ * these two config options are possible except the one below as transactional
+ * memory config pulls in CONFIG_VSX automatically.
+ *
+ * !defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ */
static int fpr_set(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
@@ -393,7 +469,27 @@ static int fpr_set(struct task_struct *target, const struct user_regset *regset,
#endif
flush_fp_to_thread(target);
-#ifdef CONFIG_VSX
+#if defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ /* copy to local buffer then write that out */
+ i = user_regset_copyin(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+ if (i)
+ return i;
+
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ for (i = 0; i < 32 ; i++)
+ target->thread.TS_TRANS_FPR(i) = buf[i];
+ target->thread.transact_fp.fpscr = buf[32];
+ } else {
+ for (i = 0; i < 32 ; i++)
+ target->thread.TS_FPR(i) = buf[i];
+ target->thread.fp_state.fpscr = buf[32];
+ }
+ return 0;
+#endif
+
+#if defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
/* copy to local buffer then write that out */
i = user_regset_copyin(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
if (i)
@@ -402,12 +498,14 @@ static int fpr_set(struct task_struct *target, const struct user_regset *regset,
target->thread.TS_FPR(i) = buf[i];
target->thread.fp_state.fpscr = buf[32];
return 0;
-#else
+#endif
+
+#if !defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
offsetof(struct thread_fp_state, fpr[32][0]));
-
return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
+
#endif
}
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 3/9] powerpc, ptrace: Enable fpr_(get/set) for transactional memory
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch enables the fpr_get which gets the running value of all
the FPR registers and the fpr_set which sets the running value of
of all the FPR registers to accommodate in transaction ptrace
interface based requests.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/kernel/ptrace.c | 110 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 104 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index f21897b..2de3b2c 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -357,6 +357,36 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
return ret;
}
+
+/**
+ * fpr_get - get FPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * When the transaction is active, 'transact_fp' holds the current running
+ * value of all FPR registers and 'fp_state' holds the last checkpointed
+ * value of all FPR registers for the current transaction. When transaction
+ * is not active 'fp_state' holds the current running state of all the FPR
+ * registers. So this function which returns the current running values of
+ * all the FPR registers, needs to know whether any transaction is active
+ * or not. The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ * };
+ *
+ * There are two config options CONFIG_VSX and CONFIG_PPC_TRANSACTIONAL_MEM
+ * which determines the final code in this function. All the combinations of
+ * these two config options are possible except the one below as transactional
+ * memory config pulls in CONFIG_VSX automatically.
+ *
+ * !defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ */
static int fpr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
@@ -367,22 +397,68 @@ static int fpr_get(struct task_struct *target, const struct user_regset *regset,
#endif
flush_fp_to_thread(target);
-#ifdef CONFIG_VSX
+#if defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ /* copy to local buffer then write that out */
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ for (i = 0; i < 32 ; i++)
+ buf[i] = target->thread.TS_TRANS_FPR(i);
+ buf[32] = target->thread.transact_fp.fpscr;
+ } else {
+ for (i = 0; i < 32 ; i++)
+ buf[i] = target->thread.TS_FPR(i);
+ buf[32] = target->thread.fp_state.fpscr;
+ }
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+#endif
+
+#if defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
/* copy to local buffer then write that out */
for (i = 0; i < 32 ; i++)
buf[i] = target->thread.TS_FPR(i);
buf[32] = target->thread.fp_state.fpscr;
return user_regset_copyout(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+#endif
-#else
+
+#if !defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
offsetof(struct thread_fp_state, fpr[32][0]));
-
return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
#endif
}
+/**
+ * fpr_set - set FPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * When the transaction is active, 'transact_fp' holds the current running
+ * value of all FPR registers and 'fp_state' holds the last checkpointed
+ * value of all FPR registers for the current transaction. When transaction
+ * is not active 'fp_state' holds the current running state of all the FPR
+ * registers. So this function which setss the current running values of
+ * all the FPR registers, needs to know whether any transaction is active
+ * or not. The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ * };
+ *
+ * There are two config options CONFIG_VSX and CONFIG_PPC_TRANSACTIONAL_MEM
+ * which determines the final code in this function. All the combinations of
+ * these two config options are possible except the one below as transactional
+ * memory config pulls in CONFIG_VSX automatically.
+ *
+ * !defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ */
static int fpr_set(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
@@ -393,7 +469,27 @@ static int fpr_set(struct task_struct *target, const struct user_regset *regset,
#endif
flush_fp_to_thread(target);
-#ifdef CONFIG_VSX
+#if defined(CONFIG_VSX) && defined(CONFIG_PPC_TRANSACTIONAL_MEM)
+ /* copy to local buffer then write that out */
+ i = user_regset_copyin(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+ if (i)
+ return i;
+
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ for (i = 0; i < 32 ; i++)
+ target->thread.TS_TRANS_FPR(i) = buf[i];
+ target->thread.transact_fp.fpscr = buf[32];
+ } else {
+ for (i = 0; i < 32 ; i++)
+ target->thread.TS_FPR(i) = buf[i];
+ target->thread.fp_state.fpscr = buf[32];
+ }
+ return 0;
+#endif
+
+#if defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
/* copy to local buffer then write that out */
i = user_regset_copyin(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
if (i)
@@ -402,12 +498,14 @@ static int fpr_set(struct task_struct *target, const struct user_regset *regset,
target->thread.TS_FPR(i) = buf[i];
target->thread.fp_state.fpscr = buf[32];
return 0;
-#else
+#endif
+
+#if !defined(CONFIG_VSX) && !defined(CONFIG_PPC_TRANSACTIONAL_MEM)
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
offsetof(struct thread_fp_state, fpr[32][0]));
-
return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
+
#endif
}
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 4/9] powerpc, ptrace: Enable vr_(get/set) for transactional memory
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch enables the vr_get which gets the running value of all
the VMX registers and the vr_set which sets the running value of
of all the VMX registers to accommodate in transaction ptrace
interface based requests.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/kernel/ptrace.c | 104 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 101 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 2de3b2c..5398c6e 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -530,10 +530,35 @@ static int vr_active(struct task_struct *target,
return target->thread.used_vr ? regset->n : 0;
}
+/**
+ * vr_get - get VR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * When the transaction is active, 'transact_vr' holds the current running
+ * value of all the VMX registers and 'vr_state' holds the last checkpointed
+ * value of all the VMX registers for the current transaction to fall back
+ * on in case it aborts. When transaction is not active 'vr_state' holds
+ * the current running state of all the VMX registers. So this function which
+ * gets the current running values of all the VMX registers, needs to know
+ * whether any transaction is active or not. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ * };
+ */
static int vr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ struct thread_vr_state *addr;
int ret;
flush_altivec_to_thread(target);
@@ -541,8 +566,19 @@ static int vr_get(struct task_struct *target, const struct user_regset *regset,
BUILD_BUG_ON(offsetof(struct thread_vr_state, vscr) !=
offsetof(struct thread_vr_state, vr[32]));
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_fp_to_thread(target);
+ flush_tmregs_to_thread(target);
+ addr = &target->thread.transact_vr;
+ } else {
+ addr = &target->thread.vr_state;
+ }
+#else
+ addr = &target->thread.vr_state;
+#endif
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- &target->thread.vr_state, 0,
+ addr, 0,
33 * sizeof(vector128));
if (!ret) {
/*
@@ -553,7 +589,16 @@ static int vr_get(struct task_struct *target, const struct user_regset *regset,
u32 word;
} vrsave;
memset(&vrsave, 0, sizeof(vrsave));
+
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr))
+ vrsave.word = target->thread.transact_vrsave;
+ else
+ vrsave.word = target->thread.vrsave;
+#else
vrsave.word = target->thread.vrsave;
+#endif
+
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &vrsave,
33 * sizeof(vector128), -1);
}
@@ -561,10 +606,35 @@ static int vr_get(struct task_struct *target, const struct user_regset *regset,
return ret;
}
+/**
+ * vr_set - set VR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * When the transaction is active, 'transact_vr' holds the current running
+ * value of all the VMX registers and 'vr_state' holds the last checkpointed
+ * value of all the VMX registers for the current transaction to fall back
+ * on in case it aborts. When transaction is not active 'vr_state' holds
+ * the current running state of all the VMX registers. So this function which
+ * sets the current running values of all the VMX registers, needs to know
+ * whether any transaction is active or not. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ * };
+ */
static int vr_set(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ struct thread_vr_state *addr;
int ret;
flush_altivec_to_thread(target);
@@ -572,8 +642,19 @@ static int vr_set(struct task_struct *target, const struct user_regset *regset,
BUILD_BUG_ON(offsetof(struct thread_vr_state, vscr) !=
offsetof(struct thread_vr_state, vr[32]));
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_fp_to_thread(target);
+ flush_tmregs_to_thread(target);
+ addr = &target->thread.transact_vr;
+ } else {
+ addr = &target->thread.vr_state;
+ }
+#else
+ addr = &target->thread.vr_state;
+#endif
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
- &target->thread.vr_state, 0,
+ addr, 0,
33 * sizeof(vector128));
if (!ret && count > 0) {
/*
@@ -584,11 +665,28 @@ static int vr_set(struct task_struct *target, const struct user_regset *regset,
u32 word;
} vrsave;
memset(&vrsave, 0, sizeof(vrsave));
+
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr))
+ vrsave.word = target->thread.transact_vrsave;
+ else
+ vrsave.word = target->thread.vrsave;
+#else
vrsave.word = target->thread.vrsave;
+#endif
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &vrsave,
33 * sizeof(vector128), -1);
- if (!ret)
+ if (!ret) {
+
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr))
+ target->thread.transact_vrsave = vrsave.word;
+ else
+ target->thread.vrsave = vrsave.word;
+#else
target->thread.vrsave = vrsave.word;
+#endif
+ }
}
return ret;
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 4/9] powerpc, ptrace: Enable vr_(get/set) for transactional memory
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch enables the vr_get which gets the running value of all
the VMX registers and the vr_set which sets the running value of
of all the VMX registers to accommodate in transaction ptrace
interface based requests.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/kernel/ptrace.c | 104 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 101 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 2de3b2c..5398c6e 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -530,10 +530,35 @@ static int vr_active(struct task_struct *target,
return target->thread.used_vr ? regset->n : 0;
}
+/**
+ * vr_get - get VR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * When the transaction is active, 'transact_vr' holds the current running
+ * value of all the VMX registers and 'vr_state' holds the last checkpointed
+ * value of all the VMX registers for the current transaction to fall back
+ * on in case it aborts. When transaction is not active 'vr_state' holds
+ * the current running state of all the VMX registers. So this function which
+ * gets the current running values of all the VMX registers, needs to know
+ * whether any transaction is active or not. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ * };
+ */
static int vr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ struct thread_vr_state *addr;
int ret;
flush_altivec_to_thread(target);
@@ -541,8 +566,19 @@ static int vr_get(struct task_struct *target, const struct user_regset *regset,
BUILD_BUG_ON(offsetof(struct thread_vr_state, vscr) !=
offsetof(struct thread_vr_state, vr[32]));
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_fp_to_thread(target);
+ flush_tmregs_to_thread(target);
+ addr = &target->thread.transact_vr;
+ } else {
+ addr = &target->thread.vr_state;
+ }
+#else
+ addr = &target->thread.vr_state;
+#endif
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- &target->thread.vr_state, 0,
+ addr, 0,
33 * sizeof(vector128));
if (!ret) {
/*
@@ -553,7 +589,16 @@ static int vr_get(struct task_struct *target, const struct user_regset *regset,
u32 word;
} vrsave;
memset(&vrsave, 0, sizeof(vrsave));
+
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr))
+ vrsave.word = target->thread.transact_vrsave;
+ else
+ vrsave.word = target->thread.vrsave;
+#else
vrsave.word = target->thread.vrsave;
+#endif
+
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &vrsave,
33 * sizeof(vector128), -1);
}
@@ -561,10 +606,35 @@ static int vr_get(struct task_struct *target, const struct user_regset *regset,
return ret;
}
+/**
+ * vr_set - set VR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * When the transaction is active, 'transact_vr' holds the current running
+ * value of all the VMX registers and 'vr_state' holds the last checkpointed
+ * value of all the VMX registers for the current transaction to fall back
+ * on in case it aborts. When transaction is not active 'vr_state' holds
+ * the current running state of all the VMX registers. So this function which
+ * sets the current running values of all the VMX registers, needs to know
+ * whether any transaction is active or not. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ * };
+ */
static int vr_set(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ struct thread_vr_state *addr;
int ret;
flush_altivec_to_thread(target);
@@ -572,8 +642,19 @@ static int vr_set(struct task_struct *target, const struct user_regset *regset,
BUILD_BUG_ON(offsetof(struct thread_vr_state, vscr) !=
offsetof(struct thread_vr_state, vr[32]));
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
+ flush_fp_to_thread(target);
+ flush_tmregs_to_thread(target);
+ addr = &target->thread.transact_vr;
+ } else {
+ addr = &target->thread.vr_state;
+ }
+#else
+ addr = &target->thread.vr_state;
+#endif
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
- &target->thread.vr_state, 0,
+ addr, 0,
33 * sizeof(vector128));
if (!ret && count > 0) {
/*
@@ -584,11 +665,28 @@ static int vr_set(struct task_struct *target, const struct user_regset *regset,
u32 word;
} vrsave;
memset(&vrsave, 0, sizeof(vrsave));
+
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr))
+ vrsave.word = target->thread.transact_vrsave;
+ else
+ vrsave.word = target->thread.vrsave;
+#else
vrsave.word = target->thread.vrsave;
+#endif
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &vrsave,
33 * sizeof(vector128), -1);
- if (!ret)
+ if (!ret) {
+
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (MSR_TM_ACTIVE(target->thread.regs->msr))
+ target->thread.transact_vrsave = vrsave.word;
+ else
+ target->thread.vrsave = vrsave.word;
+#else
target->thread.vrsave = vrsave.word;
+#endif
+ }
}
return ret;
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 5/9] powerpc, ptrace: Enable support for transactional memory register sets
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch enables get and set of transactional memory related register
sets through PTRACE_GETREGSET-PTRACE_SETREGSET interface by implementing
four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
ELF core note types added previously in this regard.
(1) NT_PPC_TM_SPR
(2) NT_PPC_TM_CGPR
(3) NT_PPC_TM_CFPR
(4) NT_PPC_TM_CVMX
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/uapi/asm/elf.h | 2 +
arch/powerpc/kernel/ptrace.c | 714 +++++++++++++++++++++++++++++++++++-
2 files changed, 701 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/elf.h b/arch/powerpc/include/uapi/asm/elf.h
index 59dad11..fdc8e2f 100644
--- a/arch/powerpc/include/uapi/asm/elf.h
+++ b/arch/powerpc/include/uapi/asm/elf.h
@@ -91,6 +91,8 @@
#define ELF_NGREG 48 /* includes nip, msr, lr, etc. */
#define ELF_NFPREG 33 /* includes fpscr */
+#define ELF_NVMX 34 /* includes all vector registers */
+#define ELF_NTMSPRREG 7 /* includes TM sprs, org_msr, dscr, tar, ppr */
typedef unsigned long elf_greg_t64;
typedef elf_greg_t64 elf_gregset_t64[ELF_NGREG];
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 5398c6e..fe22740 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -63,6 +63,11 @@ struct pt_regs_offset {
{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
#define REG_OFFSET_END {.name = NULL, .offset = 0}
+/* Some common structure offsets */
+#define TSO(f) (offsetof(struct thread_struct, f))
+#define TVSO(f) (offsetof(struct thread_vr_state, f))
+#define TFSO(f) (offsetof(struct thread_fp_state, f))
+
static const struct pt_regs_offset regoffset_table[] = {
GPR_OFFSET_NAME(0),
GPR_OFFSET_NAME(1),
@@ -809,6 +814,579 @@ static int evr_set(struct task_struct *target, const struct user_regset *regset,
}
#endif /* CONFIG_SPE */
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+/**
+ * tm_spr_active - get active number of registers in TM SPR
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks the active number of available
+ * regisers in the transactional memory SPR category.
+ */
+static int tm_spr_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_spr_get - get the TM related SPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets transactional memory related SPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct {
+ * u64 tm_tfhar;
+ * u64 tm_texasr;
+ * u64 tm_tfiar;
+ * unsigned long tm_orig_msr;
+ * unsigned long tm_tar;
+ * unsigned long tm_ppr;
+ * unsigned long tm_dscr;
+ * };
+ */
+static int tm_spr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ /* Build tests */
+ BUILD_BUG_ON(TSO(tm_tfhar) + sizeof(u64) != TSO(tm_texasr));
+ BUILD_BUG_ON(TSO(tm_texasr) + sizeof(u64) != TSO(tm_tfiar));
+ BUILD_BUG_ON(TSO(tm_tfiar) + sizeof(u64) != TSO(tm_orig_msr));
+ BUILD_BUG_ON(TSO(ckpt_regs) + sizeof(struct pt_regs) != TSO(tm_tar));
+ BUILD_BUG_ON(TSO(tm_tar) + sizeof(unsigned long) != TSO(tm_ppr));
+ BUILD_BUG_ON(TSO(tm_ppr) + sizeof(unsigned long) != TSO(tm_dscr));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ /* Flush the states */
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* TFHAR register */
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfhar, 0, sizeof(u64));
+
+ /* TEXASR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_texasr, sizeof(u64),
+ 2 * sizeof(u64));
+
+ /* TFIAR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfiar,
+ 2 * sizeof(u64), 3 * sizeof(u64));
+
+ /* TM checkpointed original MSR */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_orig_msr, 3 * sizeof(u64),
+ 3 * sizeof(u64) + sizeof(unsigned long));
+
+ /* TM checkpointed TAR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tar, 3 * sizeof(u64) +
+ sizeof(unsigned long) ,
+ 3 * sizeof(u64) + 2 * sizeof(unsigned long));
+
+ /* TM checkpointed PPR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_ppr, 3 * sizeof(u64) +
+ 2 * sizeof(unsigned long),
+ 3 * sizeof(u64) + 3 * sizeof(unsigned long));
+
+ /* TM checkpointed DSCR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_dscr, 3 * sizeof(u64) +
+ 3 * sizeof(unsigned long),
+ 3 * sizeof(u64) + 4 * sizeof(unsigned long));
+ return ret;
+}
+
+/**
+ * tm_spr_set - set the TM related SPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets transactional memory related SPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct {
+ * u64 tm_tfhar;
+ * u64 tm_texasr;
+ * u64 tm_tfiar;
+ * unsigned long tm_orig_msr;
+ * unsigned long tm_tar;
+ * unsigned long tm_ppr;
+ * unsigned long tm_dscr;
+ * };
+ */
+static int tm_spr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+
+ /* Build tests */
+ BUILD_BUG_ON(TSO(tm_tfhar) + sizeof(u64) != TSO(tm_texasr));
+ BUILD_BUG_ON(TSO(tm_texasr) + sizeof(u64) != TSO(tm_tfiar));
+ BUILD_BUG_ON(TSO(tm_tfiar) + sizeof(u64) != TSO(tm_orig_msr));
+ BUILD_BUG_ON(TSO(ckpt_regs) + sizeof(struct pt_regs) != TSO(tm_tar));
+ BUILD_BUG_ON(TSO(tm_tar) + sizeof(unsigned long) != TSO(tm_ppr));
+ BUILD_BUG_ON(TSO(tm_ppr) + sizeof(unsigned long) != TSO(tm_dscr));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ /* Flush the states */
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* TFHAR register */
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfhar, 0, sizeof(u64));
+
+ /* TEXASR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_texasr, sizeof(u64),
+ 2 * sizeof(u64));
+
+ /* TFIAR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfiar,
+ 2 * sizeof(u64), 3 * sizeof(u64));
+
+
+ /* TM checkpointed orig MSR */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_orig_msr, 3 * sizeof(u64),
+ 3 * sizeof(u64) + sizeof(unsigned long));
+
+
+ /* TM checkpointed TAR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tar, 3 * sizeof(u64) +
+ sizeof(unsigned long), 3 * sizeof(u64) +
+ 2 * sizeof(unsigned long));
+
+ /* TM checkpointed PPR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_ppr, 3 * sizeof(u64) +
+ 2 * sizeof(unsigned long), 3 * sizeof(u64) +
+ 3 * sizeof(unsigned long));
+
+ /* TM checkpointed DSCR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_dscr, 3 * sizeof(u64) +
+ 3 * sizeof(unsigned long), 3 * sizeof(u64) +
+ 4 * sizeof(unsigned long));
+ return ret;
+}
+
+/**
+ * tm_cgpr_active - get active number of registers in CGPR
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks for the active number of available
+ * regisers in transaction checkpointed GPR category.
+ */
+static int tm_cgpr_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_cgpr_get - get CGPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets transaction checkpointed GPR registers.
+ *
+ * When the transaction is active, 'ckpt_regs' holds all the checkpointed
+ * GPR register values for the current transaction to fall back on if it
+ * aborts in between. This function gets those checkpointed GPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * struct pt_regs ckpt_regs;
+ * };
+ */
+static int tm_cgpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ckpt_regs, 0,
+ sizeof(struct pt_regs));
+ return ret;
+}
+
+/*
+ * tm_cgpr_set - set the CGPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets in transaction checkpointed GPR registers.
+ *
+ * When the transaction is active, 'ckpt_regs' holds the checkpointed
+ * GPR register values for the current transaction to fall back on if it
+ * aborts in between. This function sets those checkpointed GPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * struct pt_regs ckpt_regs;
+ * };
+ */
+static int tm_cgpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ckpt_regs, 0,
+ sizeof(struct pt_regs));
+ return ret;
+}
+
+/**
+ * tm_cfpr_active - get active number of registers in CFPR
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks for the active number of available
+ * regisers in transaction checkpointed FPR category.
+ */
+static int tm_cfpr_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_cfpr_get - get CFPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets in transaction checkpointed FPR registers.
+ *
+ * When the transaction is active 'fp_state' holds the checkpointed
+ * values for the current transaction to fall back on if it aborts
+ * in between. This function gets those checkpointed FPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ *};
+ */
+static int tm_cfpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ u64 buf[33];
+ int i;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* copy to local buffer then write that out */
+ for (i = 0; i < 32 ; i++)
+ buf[i] = target->thread.TS_FPR(i);
+ buf[32] = target->thread.fp_state.fpscr;
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+}
+
+/**
+ * tm_cfpr_set - set CFPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets in transaction checkpointed FPR registers.
+ *
+ * When the transaction is active 'fp_state' holds the checkpointed
+ * FPR register values for the current transaction to fall back on
+ * if it aborts in between. This function sets these checkpointed
+ * FPR registers. The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ *};
+ */
+static int tm_cfpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ u64 buf[33];
+ int i;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* copy to local buffer then write that out */
+ i = user_regset_copyin(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+ if (i)
+ return i;
+ for (i = 0; i < 32 ; i++)
+ target->thread.TS_FPR(i) = buf[i];
+ target->thread.fp_state.fpscr = buf[32];
+ return 0;
+}
+
+/**
+ * tm_cvmx_active - get active number of registers in CVMX
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks for the active number of available
+ * regisers in checkpointed VMX category.
+ */
+static int tm_cvmx_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_cvmx_get - get CMVX registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets in transaction checkpointed VMX registers.
+ *
+ * When the transaction is active 'vr_state' and 'vr_save' hold
+ * the checkpointed values for the current transaction to fall
+ * back on if it aborts in between. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ *};
+ */
+static int tm_cvmx_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ BUILD_BUG_ON(TVSO(vscr) != TVSO(vr[32]));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ /* Flush the state */
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.vr_state, 0,
+ 33 * sizeof(vector128));
+ if (!ret) {
+ /*
+ * Copy out only the low-order word of vrsave.
+ */
+ union {
+ elf_vrreg_t reg;
+ u32 word;
+ } vrsave;
+ memset(&vrsave, 0, sizeof(vrsave));
+ vrsave.word = target->thread.vrsave;
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &vrsave,
+ 33 * sizeof(vector128), -1);
+ }
+
+ return ret;
+}
+
+/**
+ * tm_cvmx_set - set CMVX registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets in transaction checkpointed VMX registers.
+ *
+ * When the transaction is active 'vr_state' and 'vr_save' hold
+ * the checkpointed values for the current transaction to fall
+ * back on if it aborts in between. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ *};
+ */
+static int tm_cvmx_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+
+ BUILD_BUG_ON(TVSO(vscr) != TVSO(vr[32]));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.vr_state, 0,
+ 33 * sizeof(vector128));
+ if (!ret && count > 0) {
+ /*
+ * We use only the low-order word of vrsave.
+ */
+ union {
+ elf_vrreg_t reg;
+ u32 word;
+ } vrsave;
+ memset(&vrsave, 0, sizeof(vrsave));
+ vrsave.word = target->thread.vrsave;
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &vrsave,
+ 33 * sizeof(vector128), -1);
+ if (!ret)
+ target->thread.vrsave = vrsave.word;
+ }
+
+ return ret;
+}
+#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
/*
* These are our native regset flavors.
@@ -825,6 +1403,12 @@ enum powerpc_regset {
#ifdef CONFIG_SPE
REGSET_SPE,
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ REGSET_TM_SPR, /* TM specific SPR registers */
+ REGSET_TM_CGPR, /* TM checkpointed GPR registers */
+ REGSET_TM_CFPR, /* TM checkpointed FPR registers */
+ REGSET_TM_CVMX, /* TM checkpointed VMX registers */
+#endif
};
static const struct user_regset native_regsets[] = {
@@ -859,6 +1443,28 @@ static const struct user_regset native_regsets[] = {
.active = evr_active, .get = evr_get, .set = evr_set
},
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ [REGSET_TM_SPR] = {
+ .core_note_type = NT_PPC_TM_SPR, .n = ELF_NTMSPRREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .active = tm_spr_active, .get = tm_spr_get, .set = tm_spr_set
+ },
+ [REGSET_TM_CGPR] = {
+ .core_note_type = NT_PPC_TM_CGPR, .n = ELF_NGREG,
+ .size = sizeof(long), .align = sizeof(long),
+ .active = tm_cgpr_active, .get = tm_cgpr_get, .set = tm_cgpr_set
+ },
+ [REGSET_TM_CFPR] = {
+ .core_note_type = NT_PPC_TM_CFPR, .n = ELF_NFPREG,
+ .size = sizeof(double), .align = sizeof(double),
+ .active = tm_cfpr_active, .get = tm_cfpr_get, .set = tm_cfpr_set
+ },
+ [REGSET_TM_CVMX] = {
+ .core_note_type = NT_PPC_TM_CVMX, .n = ELF_NVMX,
+ .size = sizeof(vector128), .align = sizeof(vector128),
+ .active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
+ },
+#endif
};
static const struct user_regset_view user_ppc_native_view = {
@@ -869,26 +1475,38 @@ static const struct user_regset_view user_ppc_native_view = {
#ifdef CONFIG_PPC64
#include <linux/compat.h>
-static int gpr32_get(struct task_struct *target,
+static int common_gpr32_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
- void *kbuf, void __user *ubuf)
+ void *kbuf, void __user *ubuf, bool in_tm)
{
- const unsigned long *regs = &target->thread.regs->gpr[0];
+ const unsigned long *regs = NULL;
compat_ulong_t *k = kbuf;
compat_ulong_t __user *u = ubuf;
compat_ulong_t reg;
int i;
- if (target->thread.regs == NULL)
- return -EIO;
+ if (in_tm) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ regs = &target->thread.ckpt_regs.gpr[0];
+#endif
+ } else {
+ regs = &target->thread.regs->gpr[0];
- if (!FULL_REGS(target->thread.regs)) {
- /* We have a partial register set. Fill 14-31 with bogus values */
- for (i = 14; i < 32; i++)
- target->thread.regs->gpr[i] = NV_REG_POISON;
+ if (target->thread.regs == NULL)
+ return -EIO;
+
+ if (!FULL_REGS(target->thread.regs)) {
+ /*
+ * We have a partial register set.
+ * Fill 14-31 with bogus values.
+ */
+ for (i = 14; i < 32; i++)
+ target->thread.regs->gpr[i] = NV_REG_POISON;
+ }
}
+ BUG_ON(!regs);
pos /= sizeof(reg);
count /= sizeof(reg);
@@ -926,21 +1544,30 @@ static int gpr32_get(struct task_struct *target,
PT_REGS_COUNT * sizeof(reg), -1);
}
-static int gpr32_set(struct task_struct *target,
+static int common_gpr32_set(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
- const void *kbuf, const void __user *ubuf)
+ const void *kbuf, const void __user *ubuf, bool in_tm)
{
- unsigned long *regs = &target->thread.regs->gpr[0];
+ unsigned long *regs = NULL;
const compat_ulong_t *k = kbuf;
const compat_ulong_t __user *u = ubuf;
compat_ulong_t reg;
- if (target->thread.regs == NULL)
- return -EIO;
+ if (in_tm) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ regs = &target->thread.ckpt_regs.gpr[0];
+#endif
+ } else {
+ regs = &target->thread.regs->gpr[0];
- CHECK_FULL_REGS(target->thread.regs);
+ if (target->thread.regs == NULL)
+ return -EIO;
+ CHECK_FULL_REGS(target->thread.regs);
+ }
+
+ BUG_ON(!regs);
pos /= sizeof(reg);
count /= sizeof(reg);
@@ -999,6 +1626,40 @@ static int gpr32_set(struct task_struct *target,
(PT_TRAP + 1) * sizeof(reg), -1);
}
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+static int tm_cgpr32_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ return common_gpr32_get(target, regset, pos, count, kbuf, ubuf, 1);
+}
+
+static int tm_cgpr32_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ return common_gpr32_set(target, regset, pos, count, kbuf, ubuf, 1);
+}
+#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+
+static int gpr32_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ return common_gpr32_get(target, regset, pos, count, kbuf, ubuf, 0);
+}
+
+static int gpr32_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ return common_gpr32_set(target, regset, pos, count, kbuf, ubuf, 0);
+}
+
/*
* These are the regset flavors matching the CONFIG_PPC32 native set.
*/
@@ -1027,6 +1688,29 @@ static const struct user_regset compat_regsets[] = {
.active = evr_active, .get = evr_get, .set = evr_set
},
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ [REGSET_TM_SPR] = {
+ .core_note_type = NT_PPC_TM_SPR, .n = ELF_NTMSPRREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .active = tm_spr_active, .get = tm_spr_get, .set = tm_spr_set
+ },
+ [REGSET_TM_CGPR] = {
+ .core_note_type = NT_PPC_TM_CGPR, .n = ELF_NGREG,
+ .size = sizeof(long), .align = sizeof(long),
+ .active = tm_cgpr_active,
+ .get = tm_cgpr32_get, .set = tm_cgpr32_set
+ },
+ [REGSET_TM_CFPR] = {
+ .core_note_type = NT_PPC_TM_CFPR, .n = ELF_NFPREG,
+ .size = sizeof(double), .align = sizeof(double),
+ .active = tm_cfpr_active, .get = tm_cfpr_get, .set = tm_cfpr_set
+ },
+ [REGSET_TM_CVMX] = {
+ .core_note_type = NT_PPC_TM_CVMX, .n = ELF_NVMX,
+ .size = sizeof(vector128), .align = sizeof(vector128),
+ .active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
+ },
+#endif
};
static const struct user_regset_view user_ppc_compat_view = {
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 5/9] powerpc, ptrace: Enable support for transactional memory register sets
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch enables get and set of transactional memory related register
sets through PTRACE_GETREGSET-PTRACE_SETREGSET interface by implementing
four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
ELF core note types added previously in this regard.
(1) NT_PPC_TM_SPR
(2) NT_PPC_TM_CGPR
(3) NT_PPC_TM_CFPR
(4) NT_PPC_TM_CVMX
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/uapi/asm/elf.h | 2 +
arch/powerpc/kernel/ptrace.c | 714 +++++++++++++++++++++++++++++++++++-
2 files changed, 701 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/elf.h b/arch/powerpc/include/uapi/asm/elf.h
index 59dad11..fdc8e2f 100644
--- a/arch/powerpc/include/uapi/asm/elf.h
+++ b/arch/powerpc/include/uapi/asm/elf.h
@@ -91,6 +91,8 @@
#define ELF_NGREG 48 /* includes nip, msr, lr, etc. */
#define ELF_NFPREG 33 /* includes fpscr */
+#define ELF_NVMX 34 /* includes all vector registers */
+#define ELF_NTMSPRREG 7 /* includes TM sprs, org_msr, dscr, tar, ppr */
typedef unsigned long elf_greg_t64;
typedef elf_greg_t64 elf_gregset_t64[ELF_NGREG];
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 5398c6e..fe22740 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -63,6 +63,11 @@ struct pt_regs_offset {
{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
#define REG_OFFSET_END {.name = NULL, .offset = 0}
+/* Some common structure offsets */
+#define TSO(f) (offsetof(struct thread_struct, f))
+#define TVSO(f) (offsetof(struct thread_vr_state, f))
+#define TFSO(f) (offsetof(struct thread_fp_state, f))
+
static const struct pt_regs_offset regoffset_table[] = {
GPR_OFFSET_NAME(0),
GPR_OFFSET_NAME(1),
@@ -809,6 +814,579 @@ static int evr_set(struct task_struct *target, const struct user_regset *regset,
}
#endif /* CONFIG_SPE */
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+/**
+ * tm_spr_active - get active number of registers in TM SPR
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks the active number of available
+ * regisers in the transactional memory SPR category.
+ */
+static int tm_spr_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_spr_get - get the TM related SPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets transactional memory related SPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct {
+ * u64 tm_tfhar;
+ * u64 tm_texasr;
+ * u64 tm_tfiar;
+ * unsigned long tm_orig_msr;
+ * unsigned long tm_tar;
+ * unsigned long tm_ppr;
+ * unsigned long tm_dscr;
+ * };
+ */
+static int tm_spr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ /* Build tests */
+ BUILD_BUG_ON(TSO(tm_tfhar) + sizeof(u64) != TSO(tm_texasr));
+ BUILD_BUG_ON(TSO(tm_texasr) + sizeof(u64) != TSO(tm_tfiar));
+ BUILD_BUG_ON(TSO(tm_tfiar) + sizeof(u64) != TSO(tm_orig_msr));
+ BUILD_BUG_ON(TSO(ckpt_regs) + sizeof(struct pt_regs) != TSO(tm_tar));
+ BUILD_BUG_ON(TSO(tm_tar) + sizeof(unsigned long) != TSO(tm_ppr));
+ BUILD_BUG_ON(TSO(tm_ppr) + sizeof(unsigned long) != TSO(tm_dscr));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ /* Flush the states */
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* TFHAR register */
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfhar, 0, sizeof(u64));
+
+ /* TEXASR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_texasr, sizeof(u64),
+ 2 * sizeof(u64));
+
+ /* TFIAR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfiar,
+ 2 * sizeof(u64), 3 * sizeof(u64));
+
+ /* TM checkpointed original MSR */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_orig_msr, 3 * sizeof(u64),
+ 3 * sizeof(u64) + sizeof(unsigned long));
+
+ /* TM checkpointed TAR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tar, 3 * sizeof(u64) +
+ sizeof(unsigned long) ,
+ 3 * sizeof(u64) + 2 * sizeof(unsigned long));
+
+ /* TM checkpointed PPR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_ppr, 3 * sizeof(u64) +
+ 2 * sizeof(unsigned long),
+ 3 * sizeof(u64) + 3 * sizeof(unsigned long));
+
+ /* TM checkpointed DSCR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_dscr, 3 * sizeof(u64) +
+ 3 * sizeof(unsigned long),
+ 3 * sizeof(u64) + 4 * sizeof(unsigned long));
+ return ret;
+}
+
+/**
+ * tm_spr_set - set the TM related SPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets transactional memory related SPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct {
+ * u64 tm_tfhar;
+ * u64 tm_texasr;
+ * u64 tm_tfiar;
+ * unsigned long tm_orig_msr;
+ * unsigned long tm_tar;
+ * unsigned long tm_ppr;
+ * unsigned long tm_dscr;
+ * };
+ */
+static int tm_spr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+
+ /* Build tests */
+ BUILD_BUG_ON(TSO(tm_tfhar) + sizeof(u64) != TSO(tm_texasr));
+ BUILD_BUG_ON(TSO(tm_texasr) + sizeof(u64) != TSO(tm_tfiar));
+ BUILD_BUG_ON(TSO(tm_tfiar) + sizeof(u64) != TSO(tm_orig_msr));
+ BUILD_BUG_ON(TSO(ckpt_regs) + sizeof(struct pt_regs) != TSO(tm_tar));
+ BUILD_BUG_ON(TSO(tm_tar) + sizeof(unsigned long) != TSO(tm_ppr));
+ BUILD_BUG_ON(TSO(tm_ppr) + sizeof(unsigned long) != TSO(tm_dscr));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ /* Flush the states */
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* TFHAR register */
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfhar, 0, sizeof(u64));
+
+ /* TEXASR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_texasr, sizeof(u64),
+ 2 * sizeof(u64));
+
+ /* TFIAR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tfiar,
+ 2 * sizeof(u64), 3 * sizeof(u64));
+
+
+ /* TM checkpointed orig MSR */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_orig_msr, 3 * sizeof(u64),
+ 3 * sizeof(u64) + sizeof(unsigned long));
+
+
+ /* TM checkpointed TAR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_tar, 3 * sizeof(u64) +
+ sizeof(unsigned long), 3 * sizeof(u64) +
+ 2 * sizeof(unsigned long));
+
+ /* TM checkpointed PPR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_ppr, 3 * sizeof(u64) +
+ 2 * sizeof(unsigned long), 3 * sizeof(u64) +
+ 3 * sizeof(unsigned long));
+
+ /* TM checkpointed DSCR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tm_dscr, 3 * sizeof(u64) +
+ 3 * sizeof(unsigned long), 3 * sizeof(u64) +
+ 4 * sizeof(unsigned long));
+ return ret;
+}
+
+/**
+ * tm_cgpr_active - get active number of registers in CGPR
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks for the active number of available
+ * regisers in transaction checkpointed GPR category.
+ */
+static int tm_cgpr_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_cgpr_get - get CGPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets transaction checkpointed GPR registers.
+ *
+ * When the transaction is active, 'ckpt_regs' holds all the checkpointed
+ * GPR register values for the current transaction to fall back on if it
+ * aborts in between. This function gets those checkpointed GPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * struct pt_regs ckpt_regs;
+ * };
+ */
+static int tm_cgpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ckpt_regs, 0,
+ sizeof(struct pt_regs));
+ return ret;
+}
+
+/*
+ * tm_cgpr_set - set the CGPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets in transaction checkpointed GPR registers.
+ *
+ * When the transaction is active, 'ckpt_regs' holds the checkpointed
+ * GPR register values for the current transaction to fall back on if it
+ * aborts in between. This function sets those checkpointed GPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * struct pt_regs ckpt_regs;
+ * };
+ */
+static int tm_cgpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ckpt_regs, 0,
+ sizeof(struct pt_regs));
+ return ret;
+}
+
+/**
+ * tm_cfpr_active - get active number of registers in CFPR
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks for the active number of available
+ * regisers in transaction checkpointed FPR category.
+ */
+static int tm_cfpr_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_cfpr_get - get CFPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets in transaction checkpointed FPR registers.
+ *
+ * When the transaction is active 'fp_state' holds the checkpointed
+ * values for the current transaction to fall back on if it aborts
+ * in between. This function gets those checkpointed FPR registers.
+ * The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ *};
+ */
+static int tm_cfpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ u64 buf[33];
+ int i;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* copy to local buffer then write that out */
+ for (i = 0; i < 32 ; i++)
+ buf[i] = target->thread.TS_FPR(i);
+ buf[32] = target->thread.fp_state.fpscr;
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+}
+
+/**
+ * tm_cfpr_set - set CFPR registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets in transaction checkpointed FPR registers.
+ *
+ * When the transaction is active 'fp_state' holds the checkpointed
+ * FPR register values for the current transaction to fall back on
+ * if it aborts in between. This function sets these checkpointed
+ * FPR registers. The userspace interface buffer layout is as follows.
+ *
+ * struct data {
+ * u64 fpr[32];
+ * u64 fpscr;
+ *};
+ */
+static int tm_cfpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ u64 buf[33];
+ int i;
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ /* copy to local buffer then write that out */
+ i = user_regset_copyin(&pos, &count, &kbuf, &ubuf, buf, 0, -1);
+ if (i)
+ return i;
+ for (i = 0; i < 32 ; i++)
+ target->thread.TS_FPR(i) = buf[i];
+ target->thread.fp_state.fpscr = buf[32];
+ return 0;
+}
+
+/**
+ * tm_cvmx_active - get active number of registers in CVMX
+ * @target: The target task.
+ * @regset: The user regset structure.
+ *
+ * This function checks for the active number of available
+ * regisers in checkpointed VMX category.
+ */
+static int tm_cvmx_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return 0;
+
+ return regset->n;
+}
+
+/**
+ * tm_cvmx_get - get CMVX registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets in transaction checkpointed VMX registers.
+ *
+ * When the transaction is active 'vr_state' and 'vr_save' hold
+ * the checkpointed values for the current transaction to fall
+ * back on if it aborts in between. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ *};
+ */
+static int tm_cvmx_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ BUILD_BUG_ON(TVSO(vscr) != TVSO(vr[32]));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ /* Flush the state */
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.vr_state, 0,
+ 33 * sizeof(vector128));
+ if (!ret) {
+ /*
+ * Copy out only the low-order word of vrsave.
+ */
+ union {
+ elf_vrreg_t reg;
+ u32 word;
+ } vrsave;
+ memset(&vrsave, 0, sizeof(vrsave));
+ vrsave.word = target->thread.vrsave;
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &vrsave,
+ 33 * sizeof(vector128), -1);
+ }
+
+ return ret;
+}
+
+/**
+ * tm_cvmx_set - set CMVX registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets in transaction checkpointed VMX registers.
+ *
+ * When the transaction is active 'vr_state' and 'vr_save' hold
+ * the checkpointed values for the current transaction to fall
+ * back on if it aborts in between. The userspace interface buffer
+ * layout is as follows.
+ *
+ * struct data {
+ * vector128 vr[32];
+ * vector128 vscr;
+ * vector128 vrsave;
+ *};
+ */
+static int tm_cvmx_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+
+ BUILD_BUG_ON(TVSO(vscr) != TVSO(vr[32]));
+
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
+
+ if (!MSR_TM_ACTIVE(target->thread.regs->msr))
+ return -ENODATA;
+
+ flush_fp_to_thread(target);
+ flush_altivec_to_thread(target);
+ flush_tmregs_to_thread(target);
+
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.vr_state, 0,
+ 33 * sizeof(vector128));
+ if (!ret && count > 0) {
+ /*
+ * We use only the low-order word of vrsave.
+ */
+ union {
+ elf_vrreg_t reg;
+ u32 word;
+ } vrsave;
+ memset(&vrsave, 0, sizeof(vrsave));
+ vrsave.word = target->thread.vrsave;
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &vrsave,
+ 33 * sizeof(vector128), -1);
+ if (!ret)
+ target->thread.vrsave = vrsave.word;
+ }
+
+ return ret;
+}
+#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
/*
* These are our native regset flavors.
@@ -825,6 +1403,12 @@ enum powerpc_regset {
#ifdef CONFIG_SPE
REGSET_SPE,
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ REGSET_TM_SPR, /* TM specific SPR registers */
+ REGSET_TM_CGPR, /* TM checkpointed GPR registers */
+ REGSET_TM_CFPR, /* TM checkpointed FPR registers */
+ REGSET_TM_CVMX, /* TM checkpointed VMX registers */
+#endif
};
static const struct user_regset native_regsets[] = {
@@ -859,6 +1443,28 @@ static const struct user_regset native_regsets[] = {
.active = evr_active, .get = evr_get, .set = evr_set
},
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ [REGSET_TM_SPR] = {
+ .core_note_type = NT_PPC_TM_SPR, .n = ELF_NTMSPRREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .active = tm_spr_active, .get = tm_spr_get, .set = tm_spr_set
+ },
+ [REGSET_TM_CGPR] = {
+ .core_note_type = NT_PPC_TM_CGPR, .n = ELF_NGREG,
+ .size = sizeof(long), .align = sizeof(long),
+ .active = tm_cgpr_active, .get = tm_cgpr_get, .set = tm_cgpr_set
+ },
+ [REGSET_TM_CFPR] = {
+ .core_note_type = NT_PPC_TM_CFPR, .n = ELF_NFPREG,
+ .size = sizeof(double), .align = sizeof(double),
+ .active = tm_cfpr_active, .get = tm_cfpr_get, .set = tm_cfpr_set
+ },
+ [REGSET_TM_CVMX] = {
+ .core_note_type = NT_PPC_TM_CVMX, .n = ELF_NVMX,
+ .size = sizeof(vector128), .align = sizeof(vector128),
+ .active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
+ },
+#endif
};
static const struct user_regset_view user_ppc_native_view = {
@@ -869,26 +1475,38 @@ static const struct user_regset_view user_ppc_native_view = {
#ifdef CONFIG_PPC64
#include <linux/compat.h>
-static int gpr32_get(struct task_struct *target,
+static int common_gpr32_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
- void *kbuf, void __user *ubuf)
+ void *kbuf, void __user *ubuf, bool in_tm)
{
- const unsigned long *regs = &target->thread.regs->gpr[0];
+ const unsigned long *regs = NULL;
compat_ulong_t *k = kbuf;
compat_ulong_t __user *u = ubuf;
compat_ulong_t reg;
int i;
- if (target->thread.regs == NULL)
- return -EIO;
+ if (in_tm) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ regs = &target->thread.ckpt_regs.gpr[0];
+#endif
+ } else {
+ regs = &target->thread.regs->gpr[0];
- if (!FULL_REGS(target->thread.regs)) {
- /* We have a partial register set. Fill 14-31 with bogus values */
- for (i = 14; i < 32; i++)
- target->thread.regs->gpr[i] = NV_REG_POISON;
+ if (target->thread.regs == NULL)
+ return -EIO;
+
+ if (!FULL_REGS(target->thread.regs)) {
+ /*
+ * We have a partial register set.
+ * Fill 14-31 with bogus values.
+ */
+ for (i = 14; i < 32; i++)
+ target->thread.regs->gpr[i] = NV_REG_POISON;
+ }
}
+ BUG_ON(!regs);
pos /= sizeof(reg);
count /= sizeof(reg);
@@ -926,21 +1544,30 @@ static int gpr32_get(struct task_struct *target,
PT_REGS_COUNT * sizeof(reg), -1);
}
-static int gpr32_set(struct task_struct *target,
+static int common_gpr32_set(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
- const void *kbuf, const void __user *ubuf)
+ const void *kbuf, const void __user *ubuf, bool in_tm)
{
- unsigned long *regs = &target->thread.regs->gpr[0];
+ unsigned long *regs = NULL;
const compat_ulong_t *k = kbuf;
const compat_ulong_t __user *u = ubuf;
compat_ulong_t reg;
- if (target->thread.regs == NULL)
- return -EIO;
+ if (in_tm) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ regs = &target->thread.ckpt_regs.gpr[0];
+#endif
+ } else {
+ regs = &target->thread.regs->gpr[0];
- CHECK_FULL_REGS(target->thread.regs);
+ if (target->thread.regs == NULL)
+ return -EIO;
+ CHECK_FULL_REGS(target->thread.regs);
+ }
+
+ BUG_ON(!regs);
pos /= sizeof(reg);
count /= sizeof(reg);
@@ -999,6 +1626,40 @@ static int gpr32_set(struct task_struct *target,
(PT_TRAP + 1) * sizeof(reg), -1);
}
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+static int tm_cgpr32_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ return common_gpr32_get(target, regset, pos, count, kbuf, ubuf, 1);
+}
+
+static int tm_cgpr32_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ return common_gpr32_set(target, regset, pos, count, kbuf, ubuf, 1);
+}
+#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+
+static int gpr32_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ return common_gpr32_get(target, regset, pos, count, kbuf, ubuf, 0);
+}
+
+static int gpr32_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ return common_gpr32_set(target, regset, pos, count, kbuf, ubuf, 0);
+}
+
/*
* These are the regset flavors matching the CONFIG_PPC32 native set.
*/
@@ -1027,6 +1688,29 @@ static const struct user_regset compat_regsets[] = {
.active = evr_active, .get = evr_get, .set = evr_set
},
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ [REGSET_TM_SPR] = {
+ .core_note_type = NT_PPC_TM_SPR, .n = ELF_NTMSPRREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .active = tm_spr_active, .get = tm_spr_get, .set = tm_spr_set
+ },
+ [REGSET_TM_CGPR] = {
+ .core_note_type = NT_PPC_TM_CGPR, .n = ELF_NGREG,
+ .size = sizeof(long), .align = sizeof(long),
+ .active = tm_cgpr_active,
+ .get = tm_cgpr32_get, .set = tm_cgpr32_set
+ },
+ [REGSET_TM_CFPR] = {
+ .core_note_type = NT_PPC_TM_CFPR, .n = ELF_NFPREG,
+ .size = sizeof(double), .align = sizeof(double),
+ .active = tm_cfpr_active, .get = tm_cfpr_get, .set = tm_cfpr_set
+ },
+ [REGSET_TM_CVMX] = {
+ .core_note_type = NT_PPC_TM_CVMX, .n = ELF_NVMX,
+ .size = sizeof(vector128), .align = sizeof(vector128),
+ .active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
+ },
+#endif
};
static const struct user_regset_view user_ppc_compat_view = {
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 6/9] powerpc, ptrace: Enable support for miscellaneous debug registers
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch enables get and set of miscellaneous debug registers through
ptrace PTRACE_GETREGSET-PTRACE_SETREGSET interface by implementing new
powerpc specific register set REGSET_MISC support corresponding to the
new ELF core note NT_PPC_MISC added previously in this regard.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/uapi/asm/elf.h | 1 +
arch/powerpc/kernel/ptrace.c | 131 ++++++++++++++++++++++++++++++++++++
2 files changed, 132 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/elf.h b/arch/powerpc/include/uapi/asm/elf.h
index fdc8e2f..a41bd98 100644
--- a/arch/powerpc/include/uapi/asm/elf.h
+++ b/arch/powerpc/include/uapi/asm/elf.h
@@ -93,6 +93,7 @@
#define ELF_NFPREG 33 /* includes fpscr */
#define ELF_NVMX 34 /* includes all vector registers */
#define ELF_NTMSPRREG 7 /* includes TM sprs, org_msr, dscr, tar, ppr */
+#define ELF_NMISCREG 3 /* includes dscr, tar, ppr */
typedef unsigned long elf_greg_t64;
typedef elf_greg_t64 elf_gregset_t64[ELF_NGREG];
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index fe22740..eddf7df 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1388,6 +1388,122 @@ static int tm_cvmx_set(struct task_struct *target,
}
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+#ifdef CONFIG_PPC64
+/**
+ * get_misc_dbg() - get MISC debug registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets various miscellaneous debug registers which includes
+ * DSCR, PPR and TAR. The userspace intarface buffer layout is as follows.
+ *
+ * struct {
+ * unsigned long dscr;
+ * unsigned long ppr;
+ * unsigned long tar;
+ * };
+ *
+ * The data element 'tar' in the structure will be valid only if the kernel
+ * has CONFIG_PPC_BOOK3S_64 config option enabled.
+ */
+static int get_misc_dbg(struct task_struct *target,
+ const struct user_regset *regset, unsigned int pos,
+ unsigned int count, void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ /* Build test */
+ BUILD_BUG_ON(TSO(dscr) + 2 * sizeof(unsigned long) != TSO(ppr));
+
+#ifdef CONFIG_PPC_BOOK3S_64
+ BUILD_BUG_ON(TSO(ppr) + sizeof(unsigned long) != TSO(tar));
+#endif
+
+ /* DSCR register */
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.dscr, 0,
+ sizeof(unsigned long));
+
+ /* PPR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ppr,
+ sizeof(unsigned long),
+ 2 * sizeof(unsigned long));
+
+#ifdef CONFIG_PPC_BOOK3S_64
+ /* TAR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tar,
+ 2 * sizeof(unsigned long),
+ 3 * sizeof(unsigned long));
+#endif
+ return ret;
+}
+
+/**
+ * set_misc_dbg() - set MISC debug registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets various miscellaneous debug registers which includes
+ * DSCR, PPR and TAR. The userspace intarface buffer layout is as follows.
+ *
+ * struct {
+ * unsigned long dscr;
+ * unsigned long ppr;
+ * unsigned long tar;
+ * };
+ *
+ * The data element 'tar' in the structure will be valid only if the kernel
+ * has CONFIG_PPC_BOOK3S_64 config option enabled.
+ */
+static int set_misc_dbg(struct task_struct *target,
+ const struct user_regset *regset, unsigned int pos,
+ unsigned int count, const void *kbuf,
+ const void __user *ubuf)
+{
+ int ret;
+
+ /* Build test */
+ BUILD_BUG_ON(TSO(dscr) + 2 * sizeof(unsigned long) != TSO(ppr));
+
+#ifdef CONFIG_PPC_BOOK3S_64
+ BUILD_BUG_ON(TSO(ppr) + sizeof(unsigned long) != TSO(tar));
+#endif
+
+ /* DSCR register */
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.dscr, 0,
+ sizeof(unsigned long));
+
+ /* PPR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ppr,
+ sizeof(unsigned long),
+ 2 * sizeof(unsigned long));
+#ifdef CONFIG_PPC_BOOK3S_64
+ /* TAR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tar,
+ 2 * sizeof(unsigned long),
+ 3 * sizeof(unsigned long));
+#endif
+ return ret;
+}
+#endif /* CONFIG_PPC64 */
+
/*
* These are our native regset flavors.
*/
@@ -1409,6 +1525,9 @@ enum powerpc_regset {
REGSET_TM_CFPR, /* TM checkpointed FPR registers */
REGSET_TM_CVMX, /* TM checkpointed VMX registers */
#endif
+#ifdef CONFIG_PPC64
+ REGSET_MISC /* Miscellaneous debug registers */
+#endif
};
static const struct user_regset native_regsets[] = {
@@ -1465,6 +1584,13 @@ static const struct user_regset native_regsets[] = {
.active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
},
#endif
+#ifdef CONFIG_PPC64
+ [REGSET_MISC] = {
+ .core_note_type = NT_PPC_MISC, .n = ELF_NMISCREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .get = get_misc_dbg, .set = set_misc_dbg
+ },
+#endif
};
static const struct user_regset_view user_ppc_native_view = {
@@ -1711,6 +1837,11 @@ static const struct user_regset compat_regsets[] = {
.active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
},
#endif
+ [REGSET_MISC] = {
+ .core_note_type = NT_PPC_MISC, .n = ELF_NMISCREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .get = get_misc_dbg, .set = set_misc_dbg
+ },
};
static const struct user_regset_view user_ppc_compat_view = {
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 6/9] powerpc, ptrace: Enable support for miscellaneous debug registers
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch enables get and set of miscellaneous debug registers through
ptrace PTRACE_GETREGSET-PTRACE_SETREGSET interface by implementing new
powerpc specific register set REGSET_MISC support corresponding to the
new ELF core note NT_PPC_MISC added previously in this regard.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/uapi/asm/elf.h | 1 +
arch/powerpc/kernel/ptrace.c | 131 ++++++++++++++++++++++++++++++++++++
2 files changed, 132 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/elf.h b/arch/powerpc/include/uapi/asm/elf.h
index fdc8e2f..a41bd98 100644
--- a/arch/powerpc/include/uapi/asm/elf.h
+++ b/arch/powerpc/include/uapi/asm/elf.h
@@ -93,6 +93,7 @@
#define ELF_NFPREG 33 /* includes fpscr */
#define ELF_NVMX 34 /* includes all vector registers */
#define ELF_NTMSPRREG 7 /* includes TM sprs, org_msr, dscr, tar, ppr */
+#define ELF_NMISCREG 3 /* includes dscr, tar, ppr */
typedef unsigned long elf_greg_t64;
typedef elf_greg_t64 elf_gregset_t64[ELF_NGREG];
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index fe22740..eddf7df 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1388,6 +1388,122 @@ static int tm_cvmx_set(struct task_struct *target,
}
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+#ifdef CONFIG_PPC64
+/**
+ * get_misc_dbg() - get MISC debug registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy from.
+ * @ubuf: User buffer to copy into.
+ *
+ * This function gets various miscellaneous debug registers which includes
+ * DSCR, PPR and TAR. The userspace intarface buffer layout is as follows.
+ *
+ * struct {
+ * unsigned long dscr;
+ * unsigned long ppr;
+ * unsigned long tar;
+ * };
+ *
+ * The data element 'tar' in the structure will be valid only if the kernel
+ * has CONFIG_PPC_BOOK3S_64 config option enabled.
+ */
+static int get_misc_dbg(struct task_struct *target,
+ const struct user_regset *regset, unsigned int pos,
+ unsigned int count, void *kbuf, void __user *ubuf)
+{
+ int ret;
+
+ /* Build test */
+ BUILD_BUG_ON(TSO(dscr) + 2 * sizeof(unsigned long) != TSO(ppr));
+
+#ifdef CONFIG_PPC_BOOK3S_64
+ BUILD_BUG_ON(TSO(ppr) + sizeof(unsigned long) != TSO(tar));
+#endif
+
+ /* DSCR register */
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.dscr, 0,
+ sizeof(unsigned long));
+
+ /* PPR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ppr,
+ sizeof(unsigned long),
+ 2 * sizeof(unsigned long));
+
+#ifdef CONFIG_PPC_BOOK3S_64
+ /* TAR register */
+ if (!ret)
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tar,
+ 2 * sizeof(unsigned long),
+ 3 * sizeof(unsigned long));
+#endif
+ return ret;
+}
+
+/**
+ * set_misc_dbg() - set MISC debug registers
+ * @target: The target task.
+ * @regset: The user regset structure.
+ * @pos: The buffer position.
+ * @count: Number of bytes to copy.
+ * @kbuf: Kernel buffer to copy into.
+ * @ubuf: User buffer to copy from.
+ *
+ * This function sets various miscellaneous debug registers which includes
+ * DSCR, PPR and TAR. The userspace intarface buffer layout is as follows.
+ *
+ * struct {
+ * unsigned long dscr;
+ * unsigned long ppr;
+ * unsigned long tar;
+ * };
+ *
+ * The data element 'tar' in the structure will be valid only if the kernel
+ * has CONFIG_PPC_BOOK3S_64 config option enabled.
+ */
+static int set_misc_dbg(struct task_struct *target,
+ const struct user_regset *regset, unsigned int pos,
+ unsigned int count, const void *kbuf,
+ const void __user *ubuf)
+{
+ int ret;
+
+ /* Build test */
+ BUILD_BUG_ON(TSO(dscr) + 2 * sizeof(unsigned long) != TSO(ppr));
+
+#ifdef CONFIG_PPC_BOOK3S_64
+ BUILD_BUG_ON(TSO(ppr) + sizeof(unsigned long) != TSO(tar));
+#endif
+
+ /* DSCR register */
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.dscr, 0,
+ sizeof(unsigned long));
+
+ /* PPR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.ppr,
+ sizeof(unsigned long),
+ 2 * sizeof(unsigned long));
+#ifdef CONFIG_PPC_BOOK3S_64
+ /* TAR register */
+ if (!ret)
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.tar,
+ 2 * sizeof(unsigned long),
+ 3 * sizeof(unsigned long));
+#endif
+ return ret;
+}
+#endif /* CONFIG_PPC64 */
+
/*
* These are our native regset flavors.
*/
@@ -1409,6 +1525,9 @@ enum powerpc_regset {
REGSET_TM_CFPR, /* TM checkpointed FPR registers */
REGSET_TM_CVMX, /* TM checkpointed VMX registers */
#endif
+#ifdef CONFIG_PPC64
+ REGSET_MISC /* Miscellaneous debug registers */
+#endif
};
static const struct user_regset native_regsets[] = {
@@ -1465,6 +1584,13 @@ static const struct user_regset native_regsets[] = {
.active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
},
#endif
+#ifdef CONFIG_PPC64
+ [REGSET_MISC] = {
+ .core_note_type = NT_PPC_MISC, .n = ELF_NMISCREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .get = get_misc_dbg, .set = set_misc_dbg
+ },
+#endif
};
static const struct user_regset_view user_ppc_native_view = {
@@ -1711,6 +1837,11 @@ static const struct user_regset compat_regsets[] = {
.active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
},
#endif
+ [REGSET_MISC] = {
+ .core_note_type = NT_PPC_MISC, .n = ELF_NMISCREG,
+ .size = sizeof(u64), .align = sizeof(u64),
+ .get = get_misc_dbg, .set = set_misc_dbg
+ },
};
static const struct user_regset_view user_ppc_compat_view = {
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 7/9] selftests, powerpc: Add test case for TM related ptrace interface
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch adds one more test case called 'tm-ptrace' targeting TM
related ptrace interface. This test creates one child process to
run some basic TM transactions and the parent process attaches the
child to do some ptrace probing using the recently added regset
interfaces. The parent process then compares the received values
against the expected values to verify whether it has passed the
given test or not.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
tools/testing/selftests/powerpc/tm/Makefile | 2 +-
tools/testing/selftests/powerpc/tm/tm-ptrace.c | 542 +++++++++++++++++++++++++
2 files changed, 543 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/powerpc/tm/tm-ptrace.c
diff --git a/tools/testing/selftests/powerpc/tm/Makefile b/tools/testing/selftests/powerpc/tm/Makefile
index 2cede23..71d400a 100644
--- a/tools/testing/selftests/powerpc/tm/Makefile
+++ b/tools/testing/selftests/powerpc/tm/Makefile
@@ -1,4 +1,4 @@
-PROGS := tm-resched-dscr
+PROGS := tm-resched-dscr tm-ptrace
all: $(PROGS)
diff --git a/tools/testing/selftests/powerpc/tm/tm-ptrace.c b/tools/testing/selftests/powerpc/tm/tm-ptrace.c
new file mode 100644
index 0000000..7a6c7d3
--- /dev/null
+++ b/tools/testing/selftests/powerpc/tm/tm-ptrace.c
@@ -0,0 +1,542 @@
+/*
+ * Test program for TM ptrace interface
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Copyright 2014 IBM Corporation
+ *
+ * Author: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+ */
+#include <inttypes.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <malloc.h>
+#include <errno.h>
+#include <sys/ptrace.h>
+#include <sys/uio.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/signal.h>
+#include <sys/user.h>
+#include <linux/elf.h>
+#include <linux/types.h>
+
+#include "utils.h"
+
+#define TEST_PASS 0
+#define TEST_FAIL 1
+
+#define MAX_STR_LENGTH 100
+
+/* ELF core notes */
+#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
+#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
+#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
+#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
+#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
+
+/* TM instructions */
+#define TBEGIN ".long 0x7C00051D ;"
+#define TEND ".long 0x7C00055D ;"
+
+/* SPR number */
+#define SPRN_DSCR 3
+#define SPRN_TAR 815
+#define SPRN_PPR 896
+
+#define C_DSCR 10 /* TM checkpointed DSCR */
+#define C_TAR 20 /* TM checkpointed TAR */
+#define C_PPR 0x8000000000000 /* TM checkpointed PPR */
+
+#define DSCR 50 /* TM running DSCR */
+#define TAR 60 /* TM running TAR */
+#define PPR 0x4000000000000 /* TM running PPR */
+
+/* Values for GPR-FPR[0..31] */
+#define VAL0 0
+#define VAL1 1
+#define VAL2 2
+#define VAL3 3
+#define VAL4 4
+#define VAL5 5
+#define VAL6 6
+#define VAL7 7
+#define VAL8 8
+#define VAL9 9
+#define VAL10 10
+#define VAL11 11
+#define VAL12 12
+#define VAL13 13
+#define VAL14 14
+#define VAL15 15
+#define VAL_MAX 16
+
+/* Standard data types */
+typedef unsigned int u32;
+typedef __vector128 vector128;
+
+/* NT_PPC_TM_SPR buffer layout */
+struct tm_spr_regs {
+ u64 tm_tfhar;
+ u64 tm_texasr;
+ u64 tm_tfiar;
+ u64 tm_orig_msr;
+ u64 tm_tar;
+ u64 tm_ppr;
+ u64 tm_dscr;
+};
+
+/*
+ * NT_PPC_TM_CGPR buffer layout
+ *
+ * Same as that of struct pt_regs
+ */
+
+/* NT_PPC_TM_CFPR buffer layout */
+struct tm_cfpr {
+ u64 fpr[32];
+ u64 fpscr;
+};
+
+/* NT_PPC_TM_CVMX buffer layout */
+struct tm_cvmx {
+ vector128 vr[32] __attribute__((aligned(16)));
+ vector128 vscr __attribute__((aligned(16)));
+ u32 vrsave;
+};
+
+/* NT_PPC_MISC buffer layout */
+struct misc_regs {
+ u64 dscr;
+ u64 ppr;
+ u64 tar;
+};
+
+/*
+ * do_tm_transaction
+ *
+ * This functions sets the values for TAR, DSCR, PPR, GPR[0..31],
+ * FPR[0..31] registers before starting the trasanction which will
+ * enable the kernel to save them as checkpointed values. Then it
+ * starts the transaction where it loads a different set of values
+ * into the same registers again thus enabling the kernel to save
+ * them off as running values for this transaction. Then the function
+ * gets stuck forcing the process to loop at one single instruction.
+ * The transaction never finishes, thus giving the parent process
+ * the opportunity to trace the running and checkpointed values of
+ * various registers.
+ */
+void do_tm_transaction(void)
+{
+ asm __volatile__(
+ /* TM checkpointed values */
+
+ /* SPR */
+ "li 0, %[c_tar];" /* TAR */
+ "mtspr %[sprn_tar], 0;"
+ "li 0, %[c_dscr];" /* DSCR */
+ "mtspr %[sprn_dscr], 0;"
+ "or 1,1,1;" /* PPR (0x8000000000000) */
+
+ /* GPR[0..31] */
+ "li 0, %[val0];" /* GPR[0] */
+ "li 1, %[val1];" /* GPR[1] */
+ "li 2, %[val2];" /* GPR[2] */
+ "li 3, %[val3];" /* GPR[3] */
+ "li 4, %[val4];" /* GPR[4] */
+ "li 5, %[val5];" /* GPR[5] */
+ "li 6, %[val6];" /* GPR[6] */
+ "li 7, %[val7];" /* GPR[7] */
+ "li 8, %[val8];" /* GPR[8] */
+ "li 9, %[val9];" /* GPR[9] */
+ "li 10, %[val10];" /* GPR[10] */
+ "li 11, %[val11];" /* GPR[11] */
+ "li 12, %[val12];" /* GPR[12] */
+ "li 13, %[val13];" /* GPR[13] */
+ "li 14, %[val14];" /* GPR[14] */
+ "li 15, %[val15];" /* GPR[15] */
+ "li 16, %[val0];" /* GPR[16] */
+ "li 17, %[val1];" /* GPR[17] */
+ "li 18, %[val2];" /* GPR[18] */
+ "li 19, %[val3];" /* GPR[19] */
+ "li 20, %[val4];" /* GPR[20] */
+ "li 21, %[val5];" /* GPR[21] */
+ "li 22, %[val6];" /* GPR[22] */
+ "li 23, %[val7];" /* GPR[23] */
+ "li 24, %[val8];" /* GPR[24] */
+ "li 25, %[val9];" /* GPR[25] */
+ "li 26, %[val10];" /* GPR[26] */
+ "li 27, %[val11];" /* GPR[27] */
+ "li 28, %[val12];" /* GPR[28] */
+ "li 29, %[val13];" /* GPR[29] */
+ "li 30, %[val14];" /* GPR[30] */
+ "li 31, %[val15];" /* GPR[31] */
+
+ /* FPR[0..31] */
+ ".long 0x7C000166;" /* GPR[0] --> FPR[0] */
+ ".long 0x7C210166;" /* GPR[1] --> FPR[1] */
+ ".long 0x7C420166;" /* GPR[0] --> FPR[2] */
+ ".long 0x7C630166;" /* GPR[3] --> FPR[3] */
+ ".long 0x7C840166;" /* GPR[4] --> FPR[4] */
+ ".long 0x7CA50166;" /* GPR[5] --> FPR[5] */
+ ".long 0x7CC60166;" /* GPR[6] --> FPR[6] */
+ ".long 0x7CE70166;" /* GPR[7] --> FPR[7] */
+ ".long 0x7D080166;" /* GPR[8] --> FPR[8] */
+ ".long 0x7D290166;" /* GPR[9] --> FPR[9] */
+ ".long 0x7d4a0166;" /* GPR[10] --> FPR[10] */
+ ".long 0x7d6b0166;" /* GPR[11] --> FPR[11] */
+ ".long 0x7d8c0166;" /* GPR[12] --> FPR[12] */
+ ".long 0x7dad0166;" /* GPR[13] --> FPR[13] */
+ ".long 0x7dce0166;" /* GPR[14] --> FPR[14] */
+ ".long 0x7def0166;" /* GPR[15] --> FPR[15] */
+ ".long 0x7e100166;" /* GPR[16] --> FPR[16] */
+ ".long 0x7e310166;" /* GPR[17] --> FPR[17] */
+ ".long 0x7e520166;" /* GPR[18] --> FPR[18] */
+ ".long 0x7e730166;" /* GPR[19] --> FPR[19] */
+ ".long 0x7e940166;" /* GPR[20] --> FPR[20] */
+ ".long 0x7eb50166;" /* GPR[21] --> FPR[21] */
+ ".long 0x7ed60166;" /* GPR[22] --> FPR[22] */
+ ".long 0x7ef70166;" /* GPR[23] --> FPR[23] */
+ ".long 0x7f180166;" /* GPR[24] --> FPR[24] */
+ ".long 0x7f390166;" /* GPR[25] --> FPR[25] */
+ ".long 0x7f5a0166;" /* GPR[26] --> FPR[26] */
+ ".long 0x7f7b0166;" /* GPR[27] --> FPR[27] */
+ ".long 0x7f9c0166;" /* GPR[28] --> FPR[28] */
+ ".long 0x7fbd0166;" /* GPR[29] --> FPR[29] */
+ ".long 0x7fde0166;" /* GPR[30] --> FPR[30] */
+ ".long 0x7fff0166;" /* GPR[31] --> FPR[31] */
+
+ /* TM running values */
+
+ "1: ;"
+ TBEGIN
+ "beq 2f;"
+
+ /* SPR */
+ "li 0, %[tar];" /* TAR */
+ "mtspr %[sprn_tar], 0;"
+ "li 0, %[dscr];" /* DSCR */
+ "mtspr %[sprn_dscr], 0;"
+ "or 31,31,31;" /* PPR (0x4000000000000) */
+
+ /* GPR[0..31] */
+ "li 0, %[val15];" /* GPR[0] */
+ "li 1, %[val14];" /* GPR[1] */
+ "li 2, %[val13];" /* GPR[2] */
+ "li 3, %[val12];" /* GPR[3] */
+ "li 4, %[val11];" /* GPR[4] */
+ "li 5, %[val10];" /* GPR[5] */
+ "li 6, %[val9];" /* GPR[6] */
+ "li 7, %[val8];" /* GPR[7] */
+ "li 8, %[val7];" /* GPR[8] */
+ "li 9, %[val6];" /* GPR[9] */
+ "li 10, %[val5];" /* GPR[10] */
+ "li 11, %[val4];" /* GPR[11] */
+ "li 12, %[val3];" /* GPR[12] */
+ "li 13, %[val2];" /* GPR[13] */
+ "li 14, %[val1];" /* GPR[14] */
+ "li 15, %[val0];" /* GPR[15] */
+ "li 16, %[val15];" /* GPR[16] */
+ "li 17, %[val14];" /* GPR[17] */
+ "li 18, %[val13];" /* GPR[18] */
+ "li 19, %[val12];" /* GPR[19] */
+ "li 20, %[val11];" /* GPR[20] */
+ "li 21, %[val10];" /* GPR[21] */
+ "li 22, %[val9];" /* GPR[22] */
+ "li 23, %[val8];" /* GPR[23] */
+ "li 24, %[val7];" /* GPR[24] */
+ "li 25, %[val6];" /* GPR[25] */
+ "li 26, %[val5];" /* GPR[26] */
+ "li 27, %[val4];" /* GPR[27] */
+ "li 28, %[val3];" /* GPR[28] */
+ "li 29, %[val2];" /* GPR[29] */
+ "li 30, %[val1];" /* GPR[30] */
+ "li 31, %[val0];" /* GPR[31] */
+
+ /* FPR[0..31] */
+ ".long 0x7C000166;" /* GPR[0] --> FPR[0] */
+ ".long 0x7C210166;" /* GPR[1] --> FPR[1] */
+ ".long 0x7C420166;" /* GPR[2] --> FPR[2] */
+ ".long 0x7C630166;" /* GPR[3] --> FPR[3] */
+ ".long 0x7C840166;" /* GPR[4] --> FPR[4] */
+ ".long 0x7CA50166;" /* GPR[5] --> FPR[5] */
+ ".long 0x7CC60166;" /* GPR[6] --> FPR[6] */
+ ".long 0x7CE70166;" /* GPR[7] --> FPR[7] */
+ ".long 0x7D080166;" /* GPR[8] --> FPR[8] */
+ ".long 0x7D290166;" /* GPR[9] --> FPR[9] */
+ ".long 0x7d4a0166;" /* GPR[10] --> FPR[10] */
+ ".long 0x7d6b0166;" /* GPR[11] --> FPR[11] */
+ ".long 0x7d8c0166;" /* GPR[12] --> FPR[12] */
+ ".long 0x7dad0166;" /* GPR[13] --> FPR[13] */
+ ".long 0x7dce0166;" /* GPR[14] --> FPR[14] */
+ ".long 0x7def0166;" /* GPR[15] --> FPR[15] */
+ ".long 0x7e100166;" /* GPR[16] --> FPR[16] */
+ ".long 0x7e310166;" /* GPR[17] --> FPR[17] */
+ ".long 0x7e520166;" /* GPR[18] --> FPR[18] */
+ ".long 0x7e730166;" /* GPR[19] --> FPR[19] */
+ ".long 0x7e940166;" /* GPR[20] --> FPR[20] */
+ ".long 0x7eb50166;" /* GPR[21] --> FPR[21] */
+ ".long 0x7ed60166;" /* GPR[22] --> FPR[22] */
+ ".long 0x7ef70166;" /* GPR[23] --> FPR[23] */
+ ".long 0x7f180166;" /* GPR[24] --> FPR[24] */
+ ".long 0x7f390166;" /* GPR[25] --> FPR[25] */
+ ".long 0x7f5a0166;" /* GPR[26] --> FPR[26] */
+ ".long 0x7f7b0166;" /* GPR[27] --> FPR[27] */
+ ".long 0x7f9c0166;" /* GPR[28] --> FPR[28] */
+ ".long 0x7fbd0166;" /* GPR[29] --> FPR[29] */
+ ".long 0x7fde0166;" /* GPR[30] --> FPR[30] */
+ ".long 0x7fff0166;" /* GPR[31] --> FPR[31] */
+
+ "b .;" /* Get stuck here */
+ TEND
+
+ /* Transaction abort handler */
+ "2: ;"
+ "b 1b;" /* Start from TBEGIN */
+
+ :: [sprn_dscr]"i"(SPRN_DSCR), [sprn_tar]"i"(SPRN_TAR),
+ [sprn_ppr]"i"(SPRN_PPR), [val0]"i"(VAL0),
+ [val1]"i"(VAL1), [val2]"i"(VAL2), [val3]"i"(VAL3),
+ [val4]"i"(VAL4), [val5]"i"(VAL5), [val6]"i"(VAL6),
+ [val7]"i"(VAL7), [val8]"i"(VAL8), [val9]"i"(VAL9),
+ [val10]"i"(VAL10), [val11]"i"(VAL11), [val12]"i"(VAL12),
+ [val13]"i"(VAL13), [val14]"i"(VAL14), [val15]"i"(VAL15),
+ [c_tar]"i"(C_TAR), [c_dscr]"i"(C_DSCR), [tar]"i"(TAR),
+ [dscr]"i"(DSCR), [ppr]"i"(PPR), [c_ppr]"i"(C_PPR)
+ : "memory", "r7");
+}
+
+void test_result(const u64 variable, const u64 value, const char *str)
+{
+ if (variable == value)
+ printf("%s: %llx (PASSED)\n", str, variable);
+ else
+ printf("%s: %llx (FAILED)\n", str, variable);
+}
+
+int trace_tm_transaction(pid_t child)
+{
+ struct tm_spr_regs *tmspr;
+ struct pt_regs *cregs, *regs;
+ struct tm_cfpr *cfpr, *fpr;
+ struct misc_regs *mregs;
+ struct iovec iov;
+ char str[MAX_STR_LENGTH];
+ int ret, i, j;
+
+ regs = (struct pt_regs *) malloc(sizeof(struct pt_regs));
+ fpr = (struct tm_cfpr *) malloc(sizeof(struct tm_cfpr));
+
+ /* Wait till the tracee hits "b ." instruction */
+ sleep(3);
+
+ ret = ptrace(PTRACE_ATTACH, child, NULL, NULL);
+ if (ret) {
+ printf("ptrace(PTRACE_ATTACH) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ ret = waitpid(child, NULL, 0);
+ if (ret != child) {
+ printf("PID mismatch: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ /* TM specific SPR */
+ printf("Testing TM specific SPR:\n");
+ iov.iov_base = (struct tm_spr_regs *)
+ malloc(sizeof(struct tm_spr_regs));
+ iov.iov_len = sizeof(struct tm_spr_regs);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_TM_SPR, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_TM_SPR) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct tm_spr_regs)) {
+ printf("ptrace(NT_PPC_TM_SPR): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ tmspr = iov.iov_base;
+
+ printf("TFHAR: %llx\n", tmspr->tm_tfhar);
+ printf("TEXASR: %llx\n", tmspr->tm_texasr);
+ printf("TFIAR: %llx\n", tmspr->tm_tfiar);
+ printf("TM ORIG_MSR: %llx\n", tmspr->tm_orig_msr);
+
+ test_result(tmspr->tm_dscr, C_DSCR, "TM CH DSCR");
+ test_result(tmspr->tm_tar, C_TAR, "TM CH TAR");
+ test_result(tmspr->tm_ppr, C_PPR, "TM CH PPR");
+
+ /* TM checkpointed GPR */
+ printf("Testing TM checkpointed GPR:\n");
+ iov.iov_base = (struct pt_regs *) malloc(sizeof(struct pt_regs));
+ iov.iov_len = sizeof(struct pt_regs);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_TM_CGPR, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_TM_CGPR) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct pt_regs)) {
+ printf("ptrace(NT_PPC_TM_CGPR): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ cregs = iov.iov_base;
+
+ printf("TM CH NIP: %lx\n", cregs->nip);
+ printf("TM CH LINK: %lx\n", cregs->link);
+ printf("TM CH CCR: %lx\n", cregs->ccr);
+
+ for (i = 0; i < VAL_MAX; i++) {
+ sprintf(str, "TM CH GPR[%d]", i);
+ test_result(cregs->gpr[i], i, str);
+ }
+
+ for (j = 0; i < VAL_MAX * 2; j++, i++) {
+ sprintf(str, "TM CH GPR[%d]", i);
+ test_result(cregs->gpr[i], j, str);
+ }
+
+ /* TM checkpointed FPR */
+ printf("Testing TM checkpointed FPR:\n");
+ iov.iov_base = (struct tm_cfpr *) malloc(sizeof(struct tm_cfpr));
+ iov.iov_len = sizeof(struct tm_cfpr);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_TM_CFPR, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_TM_CFPR) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct tm_cfpr)) {
+ printf("ptrace(NT_PPC_TM_CFPR): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ cfpr = iov.iov_base;
+ printf("TM CH FPSCR: %llx\n", cfpr->fpscr);
+
+ for (i = 0; i < VAL_MAX; i++) {
+ sprintf(str, "TM CH FPR[%d]", i);
+ test_result(cfpr->fpr[i], i, str);
+ }
+
+ for (j = 0; i < VAL_MAX * 2; j++, i++) {
+ sprintf(str, "TM CH FPR[%d]", i);
+ test_result(cfpr->fpr[i], j, str);
+ }
+
+ /* TM running GPR */
+ printf("Testing TM running GPR:\n");
+ ret = ptrace(PTRACE_GETREGS, child, NULL, regs);
+ if (ret) {
+ printf("ptrace(PTRACE_GETREGS) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ printf("TM RN NIP: %lx\n", regs->nip);
+ printf("TM RN LINK: %lx\n", regs->link);
+ printf("TM RN CCR: %lx\n", regs->ccr);
+
+ for (i = 0, j = VAL_MAX - 1; i < VAL_MAX; i++, j--) {
+ sprintf(str, "TM RN GPR[%d]", i);
+ test_result(regs->gpr[i], j, str);
+ }
+
+ for (j = VAL_MAX - 1 ; i < VAL_MAX * 2; i++, j--) {
+ sprintf(str, "TM RN GPR[%d]", i);
+ test_result(regs->gpr[i], j, str);
+ }
+
+ /* TM running FPR */
+ printf("Testing TM running FPR:\n");
+ ret = ptrace(PTRACE_GETFPREGS, child, NULL, fpr);
+ if (ret) {
+ printf("ptrace(PTRACE_GETFPREGS) Failed: %s\n",
+ strerror(errno));
+ return TEST_FAIL;
+ }
+
+ printf("TM RN FPSCR: %llx\n", fpr->fpscr);
+
+ for (i = 0, j = VAL_MAX - 1; i < VAL_MAX; i++, j--) {
+ sprintf(str, "TM RN FPR[%d]", i);
+ test_result(fpr->fpr[i], j, str);
+ }
+
+ for (j = VAL_MAX - 1; i < VAL_MAX * 2; i++, j--) {
+ sprintf(str, "TM RN FPR[%d]", i);
+ test_result(fpr->fpr[i], j, str);
+ }
+
+ /* TM running MISC debug registers */
+ printf("Testing TM running MISC debug registers:\n");
+ iov.iov_base = (struct misc_regs *) malloc(sizeof(struct misc_regs));
+ iov.iov_len = sizeof(struct misc_regs);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_MISC, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_MISC): Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct misc_regs)) {
+ printf("ptrace(NT_PPC_TM_MISC): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ mregs = iov.iov_base;
+ test_result(mregs->dscr, DSCR, "TM RN DSCR");
+ test_result(mregs->tar, TAR, "TM RN TAR");
+ test_result(mregs->ppr, PPR, "TM RN PPR");
+
+ ret = ptrace(PTRACE_DETACH, child, NULL, NULL);
+ if (ret) {
+ printf("ptrace(PTRACE_DETACH) Failed: %s\n", strerror(errno));
+ return 1;
+ }
+
+ if (kill(child, SIGTERM)) {
+ printf("kill() Failed\n");
+ return TEST_FAIL;
+ }
+
+ ret = waitpid(child, NULL, 0);
+ if (ret != child) {
+ printf("PID mismatch: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+ return TEST_PASS;
+}
+
+int tm_ptrace_test(void)
+{
+ pid_t child;
+
+ printf("===Testing TM based PTRACE Interface===\n");
+ fflush(stdout);
+ child = fork();
+ if (child < 0) {
+ printf("fork() Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ /* Child to run the transaction */
+ if (child == 0)
+ do_tm_transaction();
+
+ /* Parent to trace the child */
+ if (child)
+ trace_tm_transaction(child);
+ return TEST_PASS;
+}
+
+int main(void)
+{
+ return test_harness(tm_ptrace_test, "tm_ptrace");
+}
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 7/9] selftests, powerpc: Add test case for TM related ptrace interface
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch adds one more test case called 'tm-ptrace' targeting TM
related ptrace interface. This test creates one child process to
run some basic TM transactions and the parent process attaches the
child to do some ptrace probing using the recently added regset
interfaces. The parent process then compares the received values
against the expected values to verify whether it has passed the
given test or not.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
tools/testing/selftests/powerpc/tm/Makefile | 2 +-
tools/testing/selftests/powerpc/tm/tm-ptrace.c | 542 +++++++++++++++++++++++++
2 files changed, 543 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/powerpc/tm/tm-ptrace.c
diff --git a/tools/testing/selftests/powerpc/tm/Makefile b/tools/testing/selftests/powerpc/tm/Makefile
index 2cede23..71d400a 100644
--- a/tools/testing/selftests/powerpc/tm/Makefile
+++ b/tools/testing/selftests/powerpc/tm/Makefile
@@ -1,4 +1,4 @@
-PROGS := tm-resched-dscr
+PROGS := tm-resched-dscr tm-ptrace
all: $(PROGS)
diff --git a/tools/testing/selftests/powerpc/tm/tm-ptrace.c b/tools/testing/selftests/powerpc/tm/tm-ptrace.c
new file mode 100644
index 0000000..7a6c7d3
--- /dev/null
+++ b/tools/testing/selftests/powerpc/tm/tm-ptrace.c
@@ -0,0 +1,542 @@
+/*
+ * Test program for TM ptrace interface
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Copyright 2014 IBM Corporation
+ *
+ * Author: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+ */
+#include <inttypes.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <malloc.h>
+#include <errno.h>
+#include <sys/ptrace.h>
+#include <sys/uio.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/signal.h>
+#include <sys/user.h>
+#include <linux/elf.h>
+#include <linux/types.h>
+
+#include "utils.h"
+
+#define TEST_PASS 0
+#define TEST_FAIL 1
+
+#define MAX_STR_LENGTH 100
+
+/* ELF core notes */
+#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
+#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
+#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
+#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
+#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
+
+/* TM instructions */
+#define TBEGIN ".long 0x7C00051D ;"
+#define TEND ".long 0x7C00055D ;"
+
+/* SPR number */
+#define SPRN_DSCR 3
+#define SPRN_TAR 815
+#define SPRN_PPR 896
+
+#define C_DSCR 10 /* TM checkpointed DSCR */
+#define C_TAR 20 /* TM checkpointed TAR */
+#define C_PPR 0x8000000000000 /* TM checkpointed PPR */
+
+#define DSCR 50 /* TM running DSCR */
+#define TAR 60 /* TM running TAR */
+#define PPR 0x4000000000000 /* TM running PPR */
+
+/* Values for GPR-FPR[0..31] */
+#define VAL0 0
+#define VAL1 1
+#define VAL2 2
+#define VAL3 3
+#define VAL4 4
+#define VAL5 5
+#define VAL6 6
+#define VAL7 7
+#define VAL8 8
+#define VAL9 9
+#define VAL10 10
+#define VAL11 11
+#define VAL12 12
+#define VAL13 13
+#define VAL14 14
+#define VAL15 15
+#define VAL_MAX 16
+
+/* Standard data types */
+typedef unsigned int u32;
+typedef __vector128 vector128;
+
+/* NT_PPC_TM_SPR buffer layout */
+struct tm_spr_regs {
+ u64 tm_tfhar;
+ u64 tm_texasr;
+ u64 tm_tfiar;
+ u64 tm_orig_msr;
+ u64 tm_tar;
+ u64 tm_ppr;
+ u64 tm_dscr;
+};
+
+/*
+ * NT_PPC_TM_CGPR buffer layout
+ *
+ * Same as that of struct pt_regs
+ */
+
+/* NT_PPC_TM_CFPR buffer layout */
+struct tm_cfpr {
+ u64 fpr[32];
+ u64 fpscr;
+};
+
+/* NT_PPC_TM_CVMX buffer layout */
+struct tm_cvmx {
+ vector128 vr[32] __attribute__((aligned(16)));
+ vector128 vscr __attribute__((aligned(16)));
+ u32 vrsave;
+};
+
+/* NT_PPC_MISC buffer layout */
+struct misc_regs {
+ u64 dscr;
+ u64 ppr;
+ u64 tar;
+};
+
+/*
+ * do_tm_transaction
+ *
+ * This functions sets the values for TAR, DSCR, PPR, GPR[0..31],
+ * FPR[0..31] registers before starting the trasanction which will
+ * enable the kernel to save them as checkpointed values. Then it
+ * starts the transaction where it loads a different set of values
+ * into the same registers again thus enabling the kernel to save
+ * them off as running values for this transaction. Then the function
+ * gets stuck forcing the process to loop at one single instruction.
+ * The transaction never finishes, thus giving the parent process
+ * the opportunity to trace the running and checkpointed values of
+ * various registers.
+ */
+void do_tm_transaction(void)
+{
+ asm __volatile__(
+ /* TM checkpointed values */
+
+ /* SPR */
+ "li 0, %[c_tar];" /* TAR */
+ "mtspr %[sprn_tar], 0;"
+ "li 0, %[c_dscr];" /* DSCR */
+ "mtspr %[sprn_dscr], 0;"
+ "or 1,1,1;" /* PPR (0x8000000000000) */
+
+ /* GPR[0..31] */
+ "li 0, %[val0];" /* GPR[0] */
+ "li 1, %[val1];" /* GPR[1] */
+ "li 2, %[val2];" /* GPR[2] */
+ "li 3, %[val3];" /* GPR[3] */
+ "li 4, %[val4];" /* GPR[4] */
+ "li 5, %[val5];" /* GPR[5] */
+ "li 6, %[val6];" /* GPR[6] */
+ "li 7, %[val7];" /* GPR[7] */
+ "li 8, %[val8];" /* GPR[8] */
+ "li 9, %[val9];" /* GPR[9] */
+ "li 10, %[val10];" /* GPR[10] */
+ "li 11, %[val11];" /* GPR[11] */
+ "li 12, %[val12];" /* GPR[12] */
+ "li 13, %[val13];" /* GPR[13] */
+ "li 14, %[val14];" /* GPR[14] */
+ "li 15, %[val15];" /* GPR[15] */
+ "li 16, %[val0];" /* GPR[16] */
+ "li 17, %[val1];" /* GPR[17] */
+ "li 18, %[val2];" /* GPR[18] */
+ "li 19, %[val3];" /* GPR[19] */
+ "li 20, %[val4];" /* GPR[20] */
+ "li 21, %[val5];" /* GPR[21] */
+ "li 22, %[val6];" /* GPR[22] */
+ "li 23, %[val7];" /* GPR[23] */
+ "li 24, %[val8];" /* GPR[24] */
+ "li 25, %[val9];" /* GPR[25] */
+ "li 26, %[val10];" /* GPR[26] */
+ "li 27, %[val11];" /* GPR[27] */
+ "li 28, %[val12];" /* GPR[28] */
+ "li 29, %[val13];" /* GPR[29] */
+ "li 30, %[val14];" /* GPR[30] */
+ "li 31, %[val15];" /* GPR[31] */
+
+ /* FPR[0..31] */
+ ".long 0x7C000166;" /* GPR[0] --> FPR[0] */
+ ".long 0x7C210166;" /* GPR[1] --> FPR[1] */
+ ".long 0x7C420166;" /* GPR[0] --> FPR[2] */
+ ".long 0x7C630166;" /* GPR[3] --> FPR[3] */
+ ".long 0x7C840166;" /* GPR[4] --> FPR[4] */
+ ".long 0x7CA50166;" /* GPR[5] --> FPR[5] */
+ ".long 0x7CC60166;" /* GPR[6] --> FPR[6] */
+ ".long 0x7CE70166;" /* GPR[7] --> FPR[7] */
+ ".long 0x7D080166;" /* GPR[8] --> FPR[8] */
+ ".long 0x7D290166;" /* GPR[9] --> FPR[9] */
+ ".long 0x7d4a0166;" /* GPR[10] --> FPR[10] */
+ ".long 0x7d6b0166;" /* GPR[11] --> FPR[11] */
+ ".long 0x7d8c0166;" /* GPR[12] --> FPR[12] */
+ ".long 0x7dad0166;" /* GPR[13] --> FPR[13] */
+ ".long 0x7dce0166;" /* GPR[14] --> FPR[14] */
+ ".long 0x7def0166;" /* GPR[15] --> FPR[15] */
+ ".long 0x7e100166;" /* GPR[16] --> FPR[16] */
+ ".long 0x7e310166;" /* GPR[17] --> FPR[17] */
+ ".long 0x7e520166;" /* GPR[18] --> FPR[18] */
+ ".long 0x7e730166;" /* GPR[19] --> FPR[19] */
+ ".long 0x7e940166;" /* GPR[20] --> FPR[20] */
+ ".long 0x7eb50166;" /* GPR[21] --> FPR[21] */
+ ".long 0x7ed60166;" /* GPR[22] --> FPR[22] */
+ ".long 0x7ef70166;" /* GPR[23] --> FPR[23] */
+ ".long 0x7f180166;" /* GPR[24] --> FPR[24] */
+ ".long 0x7f390166;" /* GPR[25] --> FPR[25] */
+ ".long 0x7f5a0166;" /* GPR[26] --> FPR[26] */
+ ".long 0x7f7b0166;" /* GPR[27] --> FPR[27] */
+ ".long 0x7f9c0166;" /* GPR[28] --> FPR[28] */
+ ".long 0x7fbd0166;" /* GPR[29] --> FPR[29] */
+ ".long 0x7fde0166;" /* GPR[30] --> FPR[30] */
+ ".long 0x7fff0166;" /* GPR[31] --> FPR[31] */
+
+ /* TM running values */
+
+ "1: ;"
+ TBEGIN
+ "beq 2f;"
+
+ /* SPR */
+ "li 0, %[tar];" /* TAR */
+ "mtspr %[sprn_tar], 0;"
+ "li 0, %[dscr];" /* DSCR */
+ "mtspr %[sprn_dscr], 0;"
+ "or 31,31,31;" /* PPR (0x4000000000000) */
+
+ /* GPR[0..31] */
+ "li 0, %[val15];" /* GPR[0] */
+ "li 1, %[val14];" /* GPR[1] */
+ "li 2, %[val13];" /* GPR[2] */
+ "li 3, %[val12];" /* GPR[3] */
+ "li 4, %[val11];" /* GPR[4] */
+ "li 5, %[val10];" /* GPR[5] */
+ "li 6, %[val9];" /* GPR[6] */
+ "li 7, %[val8];" /* GPR[7] */
+ "li 8, %[val7];" /* GPR[8] */
+ "li 9, %[val6];" /* GPR[9] */
+ "li 10, %[val5];" /* GPR[10] */
+ "li 11, %[val4];" /* GPR[11] */
+ "li 12, %[val3];" /* GPR[12] */
+ "li 13, %[val2];" /* GPR[13] */
+ "li 14, %[val1];" /* GPR[14] */
+ "li 15, %[val0];" /* GPR[15] */
+ "li 16, %[val15];" /* GPR[16] */
+ "li 17, %[val14];" /* GPR[17] */
+ "li 18, %[val13];" /* GPR[18] */
+ "li 19, %[val12];" /* GPR[19] */
+ "li 20, %[val11];" /* GPR[20] */
+ "li 21, %[val10];" /* GPR[21] */
+ "li 22, %[val9];" /* GPR[22] */
+ "li 23, %[val8];" /* GPR[23] */
+ "li 24, %[val7];" /* GPR[24] */
+ "li 25, %[val6];" /* GPR[25] */
+ "li 26, %[val5];" /* GPR[26] */
+ "li 27, %[val4];" /* GPR[27] */
+ "li 28, %[val3];" /* GPR[28] */
+ "li 29, %[val2];" /* GPR[29] */
+ "li 30, %[val1];" /* GPR[30] */
+ "li 31, %[val0];" /* GPR[31] */
+
+ /* FPR[0..31] */
+ ".long 0x7C000166;" /* GPR[0] --> FPR[0] */
+ ".long 0x7C210166;" /* GPR[1] --> FPR[1] */
+ ".long 0x7C420166;" /* GPR[2] --> FPR[2] */
+ ".long 0x7C630166;" /* GPR[3] --> FPR[3] */
+ ".long 0x7C840166;" /* GPR[4] --> FPR[4] */
+ ".long 0x7CA50166;" /* GPR[5] --> FPR[5] */
+ ".long 0x7CC60166;" /* GPR[6] --> FPR[6] */
+ ".long 0x7CE70166;" /* GPR[7] --> FPR[7] */
+ ".long 0x7D080166;" /* GPR[8] --> FPR[8] */
+ ".long 0x7D290166;" /* GPR[9] --> FPR[9] */
+ ".long 0x7d4a0166;" /* GPR[10] --> FPR[10] */
+ ".long 0x7d6b0166;" /* GPR[11] --> FPR[11] */
+ ".long 0x7d8c0166;" /* GPR[12] --> FPR[12] */
+ ".long 0x7dad0166;" /* GPR[13] --> FPR[13] */
+ ".long 0x7dce0166;" /* GPR[14] --> FPR[14] */
+ ".long 0x7def0166;" /* GPR[15] --> FPR[15] */
+ ".long 0x7e100166;" /* GPR[16] --> FPR[16] */
+ ".long 0x7e310166;" /* GPR[17] --> FPR[17] */
+ ".long 0x7e520166;" /* GPR[18] --> FPR[18] */
+ ".long 0x7e730166;" /* GPR[19] --> FPR[19] */
+ ".long 0x7e940166;" /* GPR[20] --> FPR[20] */
+ ".long 0x7eb50166;" /* GPR[21] --> FPR[21] */
+ ".long 0x7ed60166;" /* GPR[22] --> FPR[22] */
+ ".long 0x7ef70166;" /* GPR[23] --> FPR[23] */
+ ".long 0x7f180166;" /* GPR[24] --> FPR[24] */
+ ".long 0x7f390166;" /* GPR[25] --> FPR[25] */
+ ".long 0x7f5a0166;" /* GPR[26] --> FPR[26] */
+ ".long 0x7f7b0166;" /* GPR[27] --> FPR[27] */
+ ".long 0x7f9c0166;" /* GPR[28] --> FPR[28] */
+ ".long 0x7fbd0166;" /* GPR[29] --> FPR[29] */
+ ".long 0x7fde0166;" /* GPR[30] --> FPR[30] */
+ ".long 0x7fff0166;" /* GPR[31] --> FPR[31] */
+
+ "b .;" /* Get stuck here */
+ TEND
+
+ /* Transaction abort handler */
+ "2: ;"
+ "b 1b;" /* Start from TBEGIN */
+
+ :: [sprn_dscr]"i"(SPRN_DSCR), [sprn_tar]"i"(SPRN_TAR),
+ [sprn_ppr]"i"(SPRN_PPR), [val0]"i"(VAL0),
+ [val1]"i"(VAL1), [val2]"i"(VAL2), [val3]"i"(VAL3),
+ [val4]"i"(VAL4), [val5]"i"(VAL5), [val6]"i"(VAL6),
+ [val7]"i"(VAL7), [val8]"i"(VAL8), [val9]"i"(VAL9),
+ [val10]"i"(VAL10), [val11]"i"(VAL11), [val12]"i"(VAL12),
+ [val13]"i"(VAL13), [val14]"i"(VAL14), [val15]"i"(VAL15),
+ [c_tar]"i"(C_TAR), [c_dscr]"i"(C_DSCR), [tar]"i"(TAR),
+ [dscr]"i"(DSCR), [ppr]"i"(PPR), [c_ppr]"i"(C_PPR)
+ : "memory", "r7");
+}
+
+void test_result(const u64 variable, const u64 value, const char *str)
+{
+ if (variable == value)
+ printf("%s: %llx (PASSED)\n", str, variable);
+ else
+ printf("%s: %llx (FAILED)\n", str, variable);
+}
+
+int trace_tm_transaction(pid_t child)
+{
+ struct tm_spr_regs *tmspr;
+ struct pt_regs *cregs, *regs;
+ struct tm_cfpr *cfpr, *fpr;
+ struct misc_regs *mregs;
+ struct iovec iov;
+ char str[MAX_STR_LENGTH];
+ int ret, i, j;
+
+ regs = (struct pt_regs *) malloc(sizeof(struct pt_regs));
+ fpr = (struct tm_cfpr *) malloc(sizeof(struct tm_cfpr));
+
+ /* Wait till the tracee hits "b ." instruction */
+ sleep(3);
+
+ ret = ptrace(PTRACE_ATTACH, child, NULL, NULL);
+ if (ret) {
+ printf("ptrace(PTRACE_ATTACH) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ ret = waitpid(child, NULL, 0);
+ if (ret != child) {
+ printf("PID mismatch: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ /* TM specific SPR */
+ printf("Testing TM specific SPR:\n");
+ iov.iov_base = (struct tm_spr_regs *)
+ malloc(sizeof(struct tm_spr_regs));
+ iov.iov_len = sizeof(struct tm_spr_regs);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_TM_SPR, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_TM_SPR) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct tm_spr_regs)) {
+ printf("ptrace(NT_PPC_TM_SPR): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ tmspr = iov.iov_base;
+
+ printf("TFHAR: %llx\n", tmspr->tm_tfhar);
+ printf("TEXASR: %llx\n", tmspr->tm_texasr);
+ printf("TFIAR: %llx\n", tmspr->tm_tfiar);
+ printf("TM ORIG_MSR: %llx\n", tmspr->tm_orig_msr);
+
+ test_result(tmspr->tm_dscr, C_DSCR, "TM CH DSCR");
+ test_result(tmspr->tm_tar, C_TAR, "TM CH TAR");
+ test_result(tmspr->tm_ppr, C_PPR, "TM CH PPR");
+
+ /* TM checkpointed GPR */
+ printf("Testing TM checkpointed GPR:\n");
+ iov.iov_base = (struct pt_regs *) malloc(sizeof(struct pt_regs));
+ iov.iov_len = sizeof(struct pt_regs);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_TM_CGPR, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_TM_CGPR) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct pt_regs)) {
+ printf("ptrace(NT_PPC_TM_CGPR): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ cregs = iov.iov_base;
+
+ printf("TM CH NIP: %lx\n", cregs->nip);
+ printf("TM CH LINK: %lx\n", cregs->link);
+ printf("TM CH CCR: %lx\n", cregs->ccr);
+
+ for (i = 0; i < VAL_MAX; i++) {
+ sprintf(str, "TM CH GPR[%d]", i);
+ test_result(cregs->gpr[i], i, str);
+ }
+
+ for (j = 0; i < VAL_MAX * 2; j++, i++) {
+ sprintf(str, "TM CH GPR[%d]", i);
+ test_result(cregs->gpr[i], j, str);
+ }
+
+ /* TM checkpointed FPR */
+ printf("Testing TM checkpointed FPR:\n");
+ iov.iov_base = (struct tm_cfpr *) malloc(sizeof(struct tm_cfpr));
+ iov.iov_len = sizeof(struct tm_cfpr);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_TM_CFPR, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_TM_CFPR) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct tm_cfpr)) {
+ printf("ptrace(NT_PPC_TM_CFPR): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ cfpr = iov.iov_base;
+ printf("TM CH FPSCR: %llx\n", cfpr->fpscr);
+
+ for (i = 0; i < VAL_MAX; i++) {
+ sprintf(str, "TM CH FPR[%d]", i);
+ test_result(cfpr->fpr[i], i, str);
+ }
+
+ for (j = 0; i < VAL_MAX * 2; j++, i++) {
+ sprintf(str, "TM CH FPR[%d]", i);
+ test_result(cfpr->fpr[i], j, str);
+ }
+
+ /* TM running GPR */
+ printf("Testing TM running GPR:\n");
+ ret = ptrace(PTRACE_GETREGS, child, NULL, regs);
+ if (ret) {
+ printf("ptrace(PTRACE_GETREGS) Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ printf("TM RN NIP: %lx\n", regs->nip);
+ printf("TM RN LINK: %lx\n", regs->link);
+ printf("TM RN CCR: %lx\n", regs->ccr);
+
+ for (i = 0, j = VAL_MAX - 1; i < VAL_MAX; i++, j--) {
+ sprintf(str, "TM RN GPR[%d]", i);
+ test_result(regs->gpr[i], j, str);
+ }
+
+ for (j = VAL_MAX - 1 ; i < VAL_MAX * 2; i++, j--) {
+ sprintf(str, "TM RN GPR[%d]", i);
+ test_result(regs->gpr[i], j, str);
+ }
+
+ /* TM running FPR */
+ printf("Testing TM running FPR:\n");
+ ret = ptrace(PTRACE_GETFPREGS, child, NULL, fpr);
+ if (ret) {
+ printf("ptrace(PTRACE_GETFPREGS) Failed: %s\n",
+ strerror(errno));
+ return TEST_FAIL;
+ }
+
+ printf("TM RN FPSCR: %llx\n", fpr->fpscr);
+
+ for (i = 0, j = VAL_MAX - 1; i < VAL_MAX; i++, j--) {
+ sprintf(str, "TM RN FPR[%d]", i);
+ test_result(fpr->fpr[i], j, str);
+ }
+
+ for (j = VAL_MAX - 1; i < VAL_MAX * 2; i++, j--) {
+ sprintf(str, "TM RN FPR[%d]", i);
+ test_result(fpr->fpr[i], j, str);
+ }
+
+ /* TM running MISC debug registers */
+ printf("Testing TM running MISC debug registers:\n");
+ iov.iov_base = (struct misc_regs *) malloc(sizeof(struct misc_regs));
+ iov.iov_len = sizeof(struct misc_regs);
+ ret = ptrace(PTRACE_GETREGSET, child, NT_PPC_MISC, &iov);
+ if (ret) {
+ printf("ptrace(NT_PPC_MISC): Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ if (iov.iov_len != sizeof(struct misc_regs)) {
+ printf("ptrace(NT_PPC_TM_MISC): Returned wrong length\n");
+ return TEST_FAIL;
+ }
+
+ mregs = iov.iov_base;
+ test_result(mregs->dscr, DSCR, "TM RN DSCR");
+ test_result(mregs->tar, TAR, "TM RN TAR");
+ test_result(mregs->ppr, PPR, "TM RN PPR");
+
+ ret = ptrace(PTRACE_DETACH, child, NULL, NULL);
+ if (ret) {
+ printf("ptrace(PTRACE_DETACH) Failed: %s\n", strerror(errno));
+ return 1;
+ }
+
+ if (kill(child, SIGTERM)) {
+ printf("kill() Failed\n");
+ return TEST_FAIL;
+ }
+
+ ret = waitpid(child, NULL, 0);
+ if (ret != child) {
+ printf("PID mismatch: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+ return TEST_PASS;
+}
+
+int tm_ptrace_test(void)
+{
+ pid_t child;
+
+ printf("===Testing TM based PTRACE Interface===\n");
+ fflush(stdout);
+ child = fork();
+ if (child < 0) {
+ printf("fork() Failed: %s\n", strerror(errno));
+ return TEST_FAIL;
+ }
+
+ /* Child to run the transaction */
+ if (child == 0)
+ do_tm_transaction();
+
+ /* Parent to trace the child */
+ if (child)
+ trace_tm_transaction(child);
+ return TEST_PASS;
+}
+
+int main(void)
+{
+ return test_harness(tm_ptrace_test, "tm_ptrace");
+}
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 8/9] selftests, powerpc: Make GIT ignore all binaries related to TM
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch includes all the TM test binaries into the .gitignore
file listing in the same directory. This will make sure that GIT
ignores all of them while displaying status.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
tools/testing/selftests/powerpc/tm/.gitignore | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/tm/.gitignore
diff --git a/tools/testing/selftests/powerpc/tm/.gitignore b/tools/testing/selftests/powerpc/tm/.gitignore
new file mode 100644
index 0000000..71f9f9d
--- /dev/null
+++ b/tools/testing/selftests/powerpc/tm/.gitignore
@@ -0,0 +1,2 @@
+tm-ptrace
+tm-resched-dscr
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 8/9] selftests, powerpc: Make GIT ignore all binaries related to TM
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch includes all the TM test binaries into the .gitignore
file listing in the same directory. This will make sure that GIT
ignores all of them while displaying status.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
tools/testing/selftests/powerpc/tm/.gitignore | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/tm/.gitignore
diff --git a/tools/testing/selftests/powerpc/tm/.gitignore b/tools/testing/selftests/powerpc/tm/.gitignore
new file mode 100644
index 0000000..71f9f9d
--- /dev/null
+++ b/tools/testing/selftests/powerpc/tm/.gitignore
@@ -0,0 +1,2 @@
+tm-ptrace
+tm-resched-dscr
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 7:56 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, shuahkh
This patch includes all of the powerpc test binaries into the
.gitignore file listing in their respective directories. This
will make sure that GIT ignores all of these test binaries while
displaying status.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
.../testing/selftests/powerpc/copyloops/.gitignore | 4 ++++
tools/testing/selftests/powerpc/mm/.gitignore | 1 +
tools/testing/selftests/powerpc/pmu/.gitignore | 3 +++
tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 ++++++++++++++++++++++
.../selftests/powerpc/primitives/.gitignore | 1 +
5 files changed, 31 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
diff --git a/tools/testing/selftests/powerpc/copyloops/.gitignore b/tools/testing/selftests/powerpc/copyloops/.gitignore
new file mode 100644
index 0000000..25a192f
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/.gitignore
@@ -0,0 +1,4 @@
+copyuser_64
+copyuser_power7
+memcpy_64
+memcpy_power7
diff --git a/tools/testing/selftests/powerpc/mm/.gitignore b/tools/testing/selftests/powerpc/mm/.gitignore
new file mode 100644
index 0000000..156f4e8
--- /dev/null
+++ b/tools/testing/selftests/powerpc/mm/.gitignore
@@ -0,0 +1 @@
+hugetlb_vs_thp_test
diff --git a/tools/testing/selftests/powerpc/pmu/.gitignore b/tools/testing/selftests/powerpc/pmu/.gitignore
new file mode 100644
index 0000000..e748f33
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/.gitignore
@@ -0,0 +1,3 @@
+count_instructions
+l3_bank_test
+per_event_excludes
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/.gitignore b/tools/testing/selftests/powerpc/pmu/ebb/.gitignore
new file mode 100644
index 0000000..42bddbe
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/ebb/.gitignore
@@ -0,0 +1,22 @@
+reg_access_test
+event_attributes_test
+cycles_test
+cycles_with_freeze_test
+pmc56_overflow_test
+ebb_vs_cpu_event_test
+cpu_event_vs_ebb_test
+cpu_event_pinned_vs_ebb_test
+task_event_vs_ebb_test
+task_event_pinned_vs_ebb_test
+multi_ebb_procs_test
+multi_counter_test
+pmae_handling_test
+close_clears_pmcc_test
+instruction_count_test
+fork_cleanup_test
+ebb_on_child_test
+ebb_on_willing_child_test
+back_to_back_ebbs_test
+lost_exception_test
+no_handler_test
+cycles_with_mmcr2_test
diff --git a/tools/testing/selftests/powerpc/primitives/.gitignore b/tools/testing/selftests/powerpc/primitives/.gitignore
new file mode 100644
index 0000000..4cc4e31
--- /dev/null
+++ b/tools/testing/selftests/powerpc/primitives/.gitignore
@@ -0,0 +1 @@
+load_unaligned_zeropad
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite
@ 2014-12-02 7:56 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-02 7:56 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
This patch includes all of the powerpc test binaries into the
.gitignore file listing in their respective directories. This
will make sure that GIT ignores all of these test binaries while
displaying status.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
.../testing/selftests/powerpc/copyloops/.gitignore | 4 ++++
tools/testing/selftests/powerpc/mm/.gitignore | 1 +
tools/testing/selftests/powerpc/pmu/.gitignore | 3 +++
tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 ++++++++++++++++++++++
.../selftests/powerpc/primitives/.gitignore | 1 +
5 files changed, 31 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
diff --git a/tools/testing/selftests/powerpc/copyloops/.gitignore b/tools/testing/selftests/powerpc/copyloops/.gitignore
new file mode 100644
index 0000000..25a192f
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/.gitignore
@@ -0,0 +1,4 @@
+copyuser_64
+copyuser_power7
+memcpy_64
+memcpy_power7
diff --git a/tools/testing/selftests/powerpc/mm/.gitignore b/tools/testing/selftests/powerpc/mm/.gitignore
new file mode 100644
index 0000000..156f4e8
--- /dev/null
+++ b/tools/testing/selftests/powerpc/mm/.gitignore
@@ -0,0 +1 @@
+hugetlb_vs_thp_test
diff --git a/tools/testing/selftests/powerpc/pmu/.gitignore b/tools/testing/selftests/powerpc/pmu/.gitignore
new file mode 100644
index 0000000..e748f33
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/.gitignore
@@ -0,0 +1,3 @@
+count_instructions
+l3_bank_test
+per_event_excludes
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/.gitignore b/tools/testing/selftests/powerpc/pmu/ebb/.gitignore
new file mode 100644
index 0000000..42bddbe
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/ebb/.gitignore
@@ -0,0 +1,22 @@
+reg_access_test
+event_attributes_test
+cycles_test
+cycles_with_freeze_test
+pmc56_overflow_test
+ebb_vs_cpu_event_test
+cpu_event_vs_ebb_test
+cpu_event_pinned_vs_ebb_test
+task_event_vs_ebb_test
+task_event_pinned_vs_ebb_test
+multi_ebb_procs_test
+multi_counter_test
+pmae_handling_test
+close_clears_pmcc_test
+instruction_count_test
+fork_cleanup_test
+ebb_on_child_test
+ebb_on_willing_child_test
+back_to_back_ebbs_test
+lost_exception_test
+no_handler_test
+cycles_with_mmcr2_test
diff --git a/tools/testing/selftests/powerpc/primitives/.gitignore b/tools/testing/selftests/powerpc/primitives/.gitignore
new file mode 100644
index 0000000..4cc4e31
--- /dev/null
+++ b/tools/testing/selftests/powerpc/primitives/.gitignore
@@ -0,0 +1 @@
+load_unaligned_zeropad
--
1.9.3
^ permalink raw reply related [flat|nested] 80+ messages in thread
* Re: [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-02 18:23 ` Shuah Khan
-1 siblings, 0 replies; 80+ messages in thread
From: Shuah Khan @ 2014-12-02 18:23 UTC (permalink / raw)
To: Anshuman Khandual, linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov, Shuah Khan
On 12/02/2014 12:56 AM, Anshuman Khandual wrote:
> This patch includes all of the powerpc test binaries into the
> .gitignore file listing in their respective directories. This
> will make sure that GIT ignores all of these test binaries while
> displaying status.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> .../testing/selftests/powerpc/copyloops/.gitignore | 4 ++++
> tools/testing/selftests/powerpc/mm/.gitignore | 1 +
> tools/testing/selftests/powerpc/pmu/.gitignore | 3 +++
> tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 ++++++++++++++++++++++
> .../selftests/powerpc/primitives/.gitignore | 1 +
> 5 files changed, 31 insertions(+)
> create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
>
Creating a single .gitignore at tools/testing/selftests/powerpc will
make this simpler without having to add one .gitignore for each
directory underneath.
Thanks for taking on the task to add .gitignore for all powerpc
binaries.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite
@ 2014-12-02 18:23 ` Shuah Khan
0 siblings, 0 replies; 80+ messages in thread
From: Shuah Khan @ 2014-12-02 18:23 UTC (permalink / raw)
To: Anshuman Khandual, linux-kernel, linuxppc-dev
Cc: Shuah Khan, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
On 12/02/2014 12:56 AM, Anshuman Khandual wrote:
> This patch includes all of the powerpc test binaries into the
> .gitignore file listing in their respective directories. This
> will make sure that GIT ignores all of these test binaries while
> displaying status.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> .../testing/selftests/powerpc/copyloops/.gitignore | 4 ++++
> tools/testing/selftests/powerpc/mm/.gitignore | 1 +
> tools/testing/selftests/powerpc/pmu/.gitignore | 3 +++
> tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 ++++++++++++++++++++++
> .../selftests/powerpc/primitives/.gitignore | 1 +
> 5 files changed, 31 insertions(+)
> create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
> create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
>
Creating a single .gitignore at tools/testing/selftests/powerpc will
make this simpler without having to add one .gitignore for each
directory underneath.
Thanks for taking on the task to add .gitignore for all powerpc
binaries.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2014-12-02 7:56 ` Anshuman Khandual
@ 2014-12-03 5:22 ` Michael Ellerman
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Ellerman @ 2014-12-03 5:22 UTC (permalink / raw)
To: Anshuman Khandual, linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
> This patch adds four new ELF core note sections for powerpc
> transactional memory and one new ELF core note section for
> powerpc general miscellaneous debug registers. These addition
> of new ELF core note sections extends the existing ELF ABI
> without affecting it in any manner.
>
> Acked-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> include/uapi/linux/elf.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> index ea9bf25..2260fc0 100644
> --- a/include/uapi/linux/elf.h
> +++ b/include/uapi/linux/elf.h
> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
This is a really terrible name, "MISC".
Having said that, I guess it's accurate. We have a whole bunch of regs that
have accrued over recent years that aren't accessible via ptrace.
It seems to me if we're adding a misc regset we should be adding everything we
might want to it that is currenty architected.
But currently you only include the PPR, TAR & DSCR.
Looking at Power ISA v2.07, I see the following that could be included:
MMCR2
MMCRA
PMC1
PMC2
PMC3
PMC4
PMC5
PMC6
MMCR0
EBBHR
EBBRR
BESCR
SIAR
SDAR
CFAR?
Those are all new in 2.07 except for CFAR.
There might be more I missed, that was just a quick scan.
Some are only accessible when EBB is in use, maybe those could be a separate
regset.
cheers
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2014-12-03 5:22 ` Michael Ellerman
0 siblings, 0 replies; 80+ messages in thread
From: Michael Ellerman @ 2014-12-03 5:22 UTC (permalink / raw)
To: Anshuman Khandual, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves,
shuahkh, oleg, dhowells, kirjanov, tglx, davej, akpm, sukadev,
davem, sam.bobroff
On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
> This patch adds four new ELF core note sections for powerpc
> transactional memory and one new ELF core note section for
> powerpc general miscellaneous debug registers. These addition
> of new ELF core note sections extends the existing ELF ABI
> without affecting it in any manner.
>
> Acked-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> include/uapi/linux/elf.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> index ea9bf25..2260fc0 100644
> --- a/include/uapi/linux/elf.h
> +++ b/include/uapi/linux/elf.h
> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
This is a really terrible name, "MISC".
Having said that, I guess it's accurate. We have a whole bunch of regs that
have accrued over recent years that aren't accessible via ptrace.
It seems to me if we're adding a misc regset we should be adding everything we
might want to it that is currenty architected.
But currently you only include the PPR, TAR & DSCR.
Looking at Power ISA v2.07, I see the following that could be included:
MMCR2
MMCRA
PMC1
PMC2
PMC3
PMC4
PMC5
PMC6
MMCR0
EBBHR
EBBRR
BESCR
SIAR
SDAR
CFAR?
Those are all new in 2.07 except for CFAR.
There might be more I missed, that was just a quick scan.
Some are only accessible when EBB is in use, maybe those could be a separate
regset.
cheers
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite
2014-12-02 18:23 ` Shuah Khan
@ 2014-12-03 5:46 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-03 5:46 UTC (permalink / raw)
To: Shuah Khan, linux-kernel, linuxppc-dev
Cc: peterz, akpm, tglx, james.hogan, avagin, Paul.Clothier, palves,
oleg, dhowells, davej, davem, mikey, benh, sukadev, mpe,
sam.bobroff, kirjanov
On 12/02/2014 11:53 PM, Shuah Khan wrote:
> On 12/02/2014 12:56 AM, Anshuman Khandual wrote:
>> > This patch includes all of the powerpc test binaries into the
>> > .gitignore file listing in their respective directories. This
>> > will make sure that GIT ignores all of these test binaries while
>> > displaying status.
>> >
>> > Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> > ---
>> > .../testing/selftests/powerpc/copyloops/.gitignore | 4 ++++
>> > tools/testing/selftests/powerpc/mm/.gitignore | 1 +
>> > tools/testing/selftests/powerpc/pmu/.gitignore | 3 +++
>> > tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 ++++++++++++++++++++++
>> > .../selftests/powerpc/primitives/.gitignore | 1 +
>> > 5 files changed, 31 insertions(+)
>> > create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
>> >
> Creating a single .gitignore at tools/testing/selftests/powerpc will
> make this simpler without having to add one .gitignore for each
> directory underneath.
Sure, will do.
>
> Thanks for taking on the task to add .gitignore for all powerpc
> binaries.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite
@ 2014-12-03 5:46 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-03 5:46 UTC (permalink / raw)
To: Shuah Khan, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves, oleg,
davem, dhowells, kirjanov, davej, akpm, sukadev, tglx,
sam.bobroff
On 12/02/2014 11:53 PM, Shuah Khan wrote:
> On 12/02/2014 12:56 AM, Anshuman Khandual wrote:
>> > This patch includes all of the powerpc test binaries into the
>> > .gitignore file listing in their respective directories. This
>> > will make sure that GIT ignores all of these test binaries while
>> > displaying status.
>> >
>> > Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> > ---
>> > .../testing/selftests/powerpc/copyloops/.gitignore | 4 ++++
>> > tools/testing/selftests/powerpc/mm/.gitignore | 1 +
>> > tools/testing/selftests/powerpc/pmu/.gitignore | 3 +++
>> > tools/testing/selftests/powerpc/pmu/ebb/.gitignore | 22 ++++++++++++++++++++++
>> > .../selftests/powerpc/primitives/.gitignore | 1 +
>> > 5 files changed, 31 insertions(+)
>> > create mode 100644 tools/testing/selftests/powerpc/copyloops/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/mm/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/pmu/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/pmu/ebb/.gitignore
>> > create mode 100644 tools/testing/selftests/powerpc/primitives/.gitignore
>> >
> Creating a single .gitignore at tools/testing/selftests/powerpc will
> make this simpler without having to add one .gitignore for each
> directory underneath.
Sure, will do.
>
> Thanks for taking on the task to add .gitignore for all powerpc
> binaries.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2014-12-03 5:22 ` Michael Ellerman
@ 2014-12-03 6:48 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-03 6:48 UTC (permalink / raw)
To: Michael Ellerman, linux-kernel, linuxppc-dev
Cc: shuahkh, mikey, james.hogan, avagin, Paul.Clothier, peterz,
palves, oleg, davem, dhowells, kirjanov, davej, akpm, sukadev,
tglx, sam.bobroff
On 12/03/2014 10:52 AM, Michael Ellerman wrote:
> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>> This patch adds four new ELF core note sections for powerpc
>> transactional memory and one new ELF core note section for
>> powerpc general miscellaneous debug registers. These addition
>> of new ELF core note sections extends the existing ELF ABI
>> without affecting it in any manner.
>>
>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> ---
>> include/uapi/linux/elf.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>> index ea9bf25..2260fc0 100644
>> --- a/include/uapi/linux/elf.h
>> +++ b/include/uapi/linux/elf.h
>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>
> This is a really terrible name, "MISC".
>
> Having said that, I guess it's accurate. We have a whole bunch of regs that
> have accrued over recent years that aren't accessible via ptrace.
>
> It seems to me if we're adding a misc regset we should be adding everything we
> might want to it that is currenty architected.
But I believe they also need to be part of the thread_struct structure to be
accessible from ptrace.
>
> But currently you only include the PPR, TAR & DSCR.
Yeah, thats what we started with.
>
> Looking at Power ISA v2.07, I see the following that could be included:
>
> MMCR2
> MMCRA
> PMC1
> PMC2
> PMC3
> PMC4
> PMC5
> PMC6
> MMCR0
> EBBHR
> EBBRR
> BESCR
> SIAR
> SDAR
> CFAR?
MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
>
> Those are all new in 2.07 except for CFAR.
>
> There might be more I missed, that was just a quick scan.
>
> Some are only accessible when EBB is in use, maybe those could be a separate
> regset.
Yeah we can have one more regset for EBB specific registers.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2014-12-03 6:48 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-03 6:48 UTC (permalink / raw)
To: Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves,
shuahkh, oleg, dhowells, kirjanov, tglx, davej, akpm, sukadev,
davem, sam.bobroff
On 12/03/2014 10:52 AM, Michael Ellerman wrote:
> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>> This patch adds four new ELF core note sections for powerpc
>> transactional memory and one new ELF core note section for
>> powerpc general miscellaneous debug registers. These addition
>> of new ELF core note sections extends the existing ELF ABI
>> without affecting it in any manner.
>>
>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> ---
>> include/uapi/linux/elf.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>> index ea9bf25..2260fc0 100644
>> --- a/include/uapi/linux/elf.h
>> +++ b/include/uapi/linux/elf.h
>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>
> This is a really terrible name, "MISC".
>
> Having said that, I guess it's accurate. We have a whole bunch of regs that
> have accrued over recent years that aren't accessible via ptrace.
>
> It seems to me if we're adding a misc regset we should be adding everything we
> might want to it that is currenty architected.
But I believe they also need to be part of the thread_struct structure to be
accessible from ptrace.
>
> But currently you only include the PPR, TAR & DSCR.
Yeah, thats what we started with.
>
> Looking at Power ISA v2.07, I see the following that could be included:
>
> MMCR2
> MMCRA
> PMC1
> PMC2
> PMC3
> PMC4
> PMC5
> PMC6
> MMCR0
> EBBHR
> EBBRR
> BESCR
> SIAR
> SDAR
> CFAR?
MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
>
> Those are all new in 2.07 except for CFAR.
>
> There might be more I missed, that was just a quick scan.
>
> Some are only accessible when EBB is in use, maybe those could be a separate
> regset.
Yeah we can have one more regset for EBB specific registers.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2014-12-03 6:48 ` Anshuman Khandual
@ 2014-12-08 10:08 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-08 10:08 UTC (permalink / raw)
To: Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves,
shuahkh, oleg, dhowells, kirjanov, tglx, davej, akpm, sukadev,
davem, sam.bobroff
On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>> This patch adds four new ELF core note sections for powerpc
>>> transactional memory and one new ELF core note section for
>>> powerpc general miscellaneous debug registers. These addition
>>> of new ELF core note sections extends the existing ELF ABI
>>> without affecting it in any manner.
>>>
>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>> ---
>>> include/uapi/linux/elf.h | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>>> index ea9bf25..2260fc0 100644
>>> --- a/include/uapi/linux/elf.h
>>> +++ b/include/uapi/linux/elf.h
>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>>
>> This is a really terrible name, "MISC".
>>
>> Having said that, I guess it's accurate. We have a whole bunch of regs that
>> have accrued over recent years that aren't accessible via ptrace.
>>
>> It seems to me if we're adding a misc regset we should be adding everything we
>> might want to it that is currenty architected.
>
> But I believe they also need to be part of the thread_struct structure to be
> accessible from ptrace.
Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
during the process context switch. So the values of PMC1..PMC6 are not
thread specific in the structure. To be able to access them in ptrace
when the tracee has stopped, we need to context save these counters
in the thread struct. Shall we do that ? Then we can add them to the
MISC regset bucket irrespective of whats the value we get in there when
we probe through ptrace.
The same goes for MMCRA, CFAR registers as well.
>
>>
>> But currently you only include the PPR, TAR & DSCR.
>
> Yeah, thats what we started with.
>
>>
>> Looking at Power ISA v2.07, I see the following that could be included:
>>
>> MMCR2
>> MMCRA
>> PMC1
>> PMC2
>> PMC3
>> PMC4
>> PMC5
>> PMC6
>> MMCR0
>> EBBHR
>> EBBRR
>> BESCR
>> SIAR
>> SDAR
>> CFAR?
>
> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
>
>>
>> Those are all new in 2.07 except for CFAR.
>>
>> There might be more I missed, that was just a quick scan.
>>
>> Some are only accessible when EBB is in use, maybe those could be a separate
>> regset.
>
> Yeah we can have one more regset for EBB specific registers.
Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
was thinking about putting these five registers into the MISC bucket instead.
But from the perf code, it looks like these five registers are also related to
the EBB context as well.
Some clarity on these points would really help.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2014-12-08 10:08 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2014-12-08 10:08 UTC (permalink / raw)
To: Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, davem, peterz, palves,
shuahkh, oleg, dhowells, kirjanov, davej, tglx, sukadev, akpm,
sam.bobroff
On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>> This patch adds four new ELF core note sections for powerpc
>>> transactional memory and one new ELF core note section for
>>> powerpc general miscellaneous debug registers. These addition
>>> of new ELF core note sections extends the existing ELF ABI
>>> without affecting it in any manner.
>>>
>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>> ---
>>> include/uapi/linux/elf.h | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>>> index ea9bf25..2260fc0 100644
>>> --- a/include/uapi/linux/elf.h
>>> +++ b/include/uapi/linux/elf.h
>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>>
>> This is a really terrible name, "MISC".
>>
>> Having said that, I guess it's accurate. We have a whole bunch of regs that
>> have accrued over recent years that aren't accessible via ptrace.
>>
>> It seems to me if we're adding a misc regset we should be adding everything we
>> might want to it that is currenty architected.
>
> But I believe they also need to be part of the thread_struct structure to be
> accessible from ptrace.
Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
during the process context switch. So the values of PMC1..PMC6 are not
thread specific in the structure. To be able to access them in ptrace
when the tracee has stopped, we need to context save these counters
in the thread struct. Shall we do that ? Then we can add them to the
MISC regset bucket irrespective of whats the value we get in there when
we probe through ptrace.
The same goes for MMCRA, CFAR registers as well.
>
>>
>> But currently you only include the PPR, TAR & DSCR.
>
> Yeah, thats what we started with.
>
>>
>> Looking at Power ISA v2.07, I see the following that could be included:
>>
>> MMCR2
>> MMCRA
>> PMC1
>> PMC2
>> PMC3
>> PMC4
>> PMC5
>> PMC6
>> MMCR0
>> EBBHR
>> EBBRR
>> BESCR
>> SIAR
>> SDAR
>> CFAR?
>
> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
>
>>
>> Those are all new in 2.07 except for CFAR.
>>
>> There might be more I missed, that was just a quick scan.
>>
>> Some are only accessible when EBB is in use, maybe those could be a separate
>> regset.
>
> Yeah we can have one more regset for EBB specific registers.
Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
was thinking about putting these five registers into the MISC bucket instead.
But from the perf code, it looks like these five registers are also related to
the EBB context as well.
Some clarity on these points would really help.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2014-12-08 10:08 ` Anshuman Khandual
@ 2014-12-19 19:28 ` Edjunior Barbosa Machado
-1 siblings, 0 replies; 80+ messages in thread
From: Edjunior Barbosa Machado @ 2014-12-19 19:28 UTC (permalink / raw)
To: Anshuman Khandual, Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, davem, peterz, palves,
shuahkh, oleg, dhowells, kirjanov, davej, tglx, sukadev, akpm,
sam.bobroff, Ulrich Weigand
On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
> On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
>> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>>> This patch adds four new ELF core note sections for powerpc
>>>> transactional memory and one new ELF core note section for
>>>> powerpc general miscellaneous debug registers. These addition
>>>> of new ELF core note sections extends the existing ELF ABI
>>>> without affecting it in any manner.
>>>>
>>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>>> ---
>>>> include/uapi/linux/elf.h | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>>>> index ea9bf25..2260fc0 100644
>>>> --- a/include/uapi/linux/elf.h
>>>> +++ b/include/uapi/linux/elf.h
>>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>>>
>>> This is a really terrible name, "MISC".
>>>
>>> Having said that, I guess it's accurate. We have a whole bunch of regs that
>>> have accrued over recent years that aren't accessible via ptrace.
>>>
>>> It seems to me if we're adding a misc regset we should be adding everything we
>>> might want to it that is currenty architected.
>>
>> But I believe they also need to be part of the thread_struct structure to be
>> accessible from ptrace.
>
> Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
> during the process context switch. So the values of PMC1..PMC6 are not
> thread specific in the structure. To be able to access them in ptrace
> when the tracee has stopped, we need to context save these counters
> in the thread struct. Shall we do that ? Then we can add them to the
> MISC regset bucket irrespective of whats the value we get in there when
> we probe through ptrace.
>
> The same goes for MMCRA, CFAR registers as well.
>
>>
>>>
>>> But currently you only include the PPR, TAR & DSCR.
>>
>> Yeah, thats what we started with.
>>
>>>
>>> Looking at Power ISA v2.07, I see the following that could be included:
>>>
>>> MMCR2
>>> MMCRA
>>> PMC1
>>> PMC2
>>> PMC3
>>> PMC4
>>> PMC5
>>> PMC6
>>> MMCR0
>>> EBBHR
>>> EBBRR
>>> BESCR
>>> SIAR
>>> SDAR
>>> CFAR?
>>
>> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
>
> Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
>
>>
>>>
>>> Those are all new in 2.07 except for CFAR.
>>>
>>> There might be more I missed, that was just a quick scan.
>>>
>>> Some are only accessible when EBB is in use, maybe those could be a separate
>>> regset.
>>
>> Yeah we can have one more regset for EBB specific registers.
>
> Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
> or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
> was thinking about putting these five registers into the MISC bucket instead.
> But from the perf code, it looks like these five registers are also related to
> the EBB context as well.
>
> Some clarity on these points would really help.
Hi,
from the provided testcase using ptrace interface, reviewing with the help
of Ulrich, it looks OK from GDB perspective, with the exception of a few
concerns:
The patchset seems to change the "original" ptrace requests (i.e.
PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" state, and
adds new register sets to return the "checkpointed" state. Considering that
whenever you get a debugger interception inside a transactional block, the
transaction will abort, we're wondering if it wouldn't make more sense to
display the 'checkpointed' state as the normal registers since this is where the
execution will continue from.
Also, we've noticed that the 'misc' regset contains registers from different ISA
versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
there is a way to detect presence/validity of such registers, but perhaps it
might be a good idea to separate registers from different ISAs in different
regsets.
Regarding the inclusion of other registers along with the EBB-related ones, I'm
sorry but I'm not familiar with them.
Thanks and regards,
--
Edjunior
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2014-12-19 19:28 ` Edjunior Barbosa Machado
0 siblings, 0 replies; 80+ messages in thread
From: Edjunior Barbosa Machado @ 2014-12-19 19:28 UTC (permalink / raw)
To: Anshuman Khandual, Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves,
Ulrich Weigand, shuahkh, akpm, oleg, dhowells, kirjanov, davej,
tglx, sukadev, davem, sam.bobroff
On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
> On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
>> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>>> This patch adds four new ELF core note sections for powerpc
>>>> transactional memory and one new ELF core note section for
>>>> powerpc general miscellaneous debug registers. These addition
>>>> of new ELF core note sections extends the existing ELF ABI
>>>> without affecting it in any manner.
>>>>
>>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>>> ---
>>>> include/uapi/linux/elf.h | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>>>> index ea9bf25..2260fc0 100644
>>>> --- a/include/uapi/linux/elf.h
>>>> +++ b/include/uapi/linux/elf.h
>>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>>>
>>> This is a really terrible name, "MISC".
>>>
>>> Having said that, I guess it's accurate. We have a whole bunch of regs that
>>> have accrued over recent years that aren't accessible via ptrace.
>>>
>>> It seems to me if we're adding a misc regset we should be adding everything we
>>> might want to it that is currenty architected.
>>
>> But I believe they also need to be part of the thread_struct structure to be
>> accessible from ptrace.
>
> Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
> during the process context switch. So the values of PMC1..PMC6 are not
> thread specific in the structure. To be able to access them in ptrace
> when the tracee has stopped, we need to context save these counters
> in the thread struct. Shall we do that ? Then we can add them to the
> MISC regset bucket irrespective of whats the value we get in there when
> we probe through ptrace.
>
> The same goes for MMCRA, CFAR registers as well.
>
>>
>>>
>>> But currently you only include the PPR, TAR & DSCR.
>>
>> Yeah, thats what we started with.
>>
>>>
>>> Looking at Power ISA v2.07, I see the following that could be included:
>>>
>>> MMCR2
>>> MMCRA
>>> PMC1
>>> PMC2
>>> PMC3
>>> PMC4
>>> PMC5
>>> PMC6
>>> MMCR0
>>> EBBHR
>>> EBBRR
>>> BESCR
>>> SIAR
>>> SDAR
>>> CFAR?
>>
>> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
>
> Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
>
>>
>>>
>>> Those are all new in 2.07 except for CFAR.
>>>
>>> There might be more I missed, that was just a quick scan.
>>>
>>> Some are only accessible when EBB is in use, maybe those could be a separate
>>> regset.
>>
>> Yeah we can have one more regset for EBB specific registers.
>
> Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
> or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
> was thinking about putting these five registers into the MISC bucket instead.
> But from the perf code, it looks like these five registers are also related to
> the EBB context as well.
>
> Some clarity on these points would really help.
Hi,
from the provided testcase using ptrace interface, reviewing with the help
of Ulrich, it looks OK from GDB perspective, with the exception of a few
concerns:
The patchset seems to change the "original" ptrace requests (i.e.
PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" state, and
adds new register sets to return the "checkpointed" state. Considering that
whenever you get a debugger interception inside a transactional block, the
transaction will abort, we're wondering if it wouldn't make more sense to
display the 'checkpointed' state as the normal registers since this is where the
execution will continue from.
Also, we've noticed that the 'misc' regset contains registers from different ISA
versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
there is a way to detect presence/validity of such registers, but perhaps it
might be a good idea to separate registers from different ISAs in different
regsets.
Regarding the inclusion of other registers along with the EBB-related ones, I'm
sorry but I'm not familiar with them.
Thanks and regards,
--
Edjunior
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2014-12-19 19:28 ` Edjunior Barbosa Machado
@ 2015-01-01 8:08 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-01-01 8:08 UTC (permalink / raw)
To: Edjunior Barbosa Machado, Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, davem, peterz, palves,
shuahkh, oleg, dhowells, kirjanov, davej, tglx, sukadev, akpm,
sam.bobroff, Ulrich Weigand
On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
>> On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
>>> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>>>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>>>> This patch adds four new ELF core note sections for powerpc
>>>>> transactional memory and one new ELF core note section for
>>>>> powerpc general miscellaneous debug registers. These addition
>>>>> of new ELF core note sections extends the existing ELF ABI
>>>>> without affecting it in any manner.
>>>>>
>>>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>>>> ---
>>>>> include/uapi/linux/elf.h | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>>>>> index ea9bf25..2260fc0 100644
>>>>> --- a/include/uapi/linux/elf.h
>>>>> +++ b/include/uapi/linux/elf.h
>>>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>>>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>>>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>>>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>>>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>>>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>>>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>>>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>>>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>>>>
>>>> This is a really terrible name, "MISC".
>>>>
>>>> Having said that, I guess it's accurate. We have a whole bunch of regs that
>>>> have accrued over recent years that aren't accessible via ptrace.
>>>>
>>>> It seems to me if we're adding a misc regset we should be adding everything we
>>>> might want to it that is currenty architected.
>>>
>>> But I believe they also need to be part of the thread_struct structure to be
>>> accessible from ptrace.
>>
>> Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
>> during the process context switch. So the values of PMC1..PMC6 are not
>> thread specific in the structure. To be able to access them in ptrace
>> when the tracee has stopped, we need to context save these counters
>> in the thread struct. Shall we do that ? Then we can add them to the
>> MISC regset bucket irrespective of whats the value we get in there when
>> we probe through ptrace.
>>
>> The same goes for MMCRA, CFAR registers as well.
>>
>>>
>>>>
>>>> But currently you only include the PPR, TAR & DSCR.
>>>
>>> Yeah, thats what we started with.
>>>
>>>>
>>>> Looking at Power ISA v2.07, I see the following that could be included:
>>>>
>>>> MMCR2
>>>> MMCRA
>>>> PMC1
>>>> PMC2
>>>> PMC3
>>>> PMC4
>>>> PMC5
>>>> PMC6
>>>> MMCR0
>>>> EBBHR
>>>> EBBRR
>>>> BESCR
>>>> SIAR
>>>> SDAR
>>>> CFAR?
>>>
>>> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
>>
>> Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
>>
>>>
>>>>
>>>> Those are all new in 2.07 except for CFAR.
>>>>
>>>> There might be more I missed, that was just a quick scan.
>>>>
>>>> Some are only accessible when EBB is in use, maybe those could be a separate
>>>> regset.
>>>
>>> Yeah we can have one more regset for EBB specific registers.
>>
>> Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
>> or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
>> was thinking about putting these five registers into the MISC bucket instead.
>> But from the perf code, it looks like these five registers are also related to
>> the EBB context as well.
>>
>> Some clarity on these points would really help.
>
> Hi,
>
> from the provided testcase using ptrace interface, reviewing with the help
> of Ulrich, it looks OK from GDB perspective, with the exception of a few
> concerns:
>
> The patchset seems to change the "original" ptrace requests (i.e.
> PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" state, and
> adds new register sets to return the "checkpointed" state. Considering that
> whenever you get a debugger interception inside a transactional block, the
> transaction will abort, we're wondering if it wouldn't make more sense to
> display the 'checkpointed' state as the normal registers since this is where the
> execution will continue from.
Debugger interception (trace interrupt) in between any transaction block will abort
it ? I doubt that. The tracee process will just stop, it's context gets saved in the
kernel so that it can again start executing from the exact same point onward when it
resumes. If this happens when inside any transaction block, the transaction's running
context and check pointed context will get saved. The execution will again start from
the running context values instead of check pointed when the process resumes. Check
pointed values will be loaded back into the context when the transaction finishes.
Inside transaction both running and check pointed values can be probed independently.
>
> Also, we've noticed that the 'misc' regset contains registers from different ISA
> versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
> there is a way to detect presence/validity of such registers, but perhaps it
> might be a good idea to separate registers from different ISAs in different
> regsets.
Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we are v2.07
compliant) to detect whether TAR register is available or not.
>
> Regarding the inclusion of other registers along with the EBB-related ones, I'm
> sorry but I'm not familiar with them.
Michael Ellerman mentioned that we can look into them separately sometime later
not in this patch series.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-01-01 8:08 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-01-01 8:08 UTC (permalink / raw)
To: Edjunior Barbosa Machado, Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves,
Ulrich Weigand, shuahkh, akpm, oleg, dhowells, kirjanov, davej,
tglx, sukadev, davem, sam.bobroff
On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
>> On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
>>> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>>>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>>>> This patch adds four new ELF core note sections for powerpc
>>>>> transactional memory and one new ELF core note section for
>>>>> powerpc general miscellaneous debug registers. These addition
>>>>> of new ELF core note sections extends the existing ELF ABI
>>>>> without affecting it in any manner.
>>>>>
>>>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>>>> ---
>>>>> include/uapi/linux/elf.h | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>>>>> index ea9bf25..2260fc0 100644
>>>>> --- a/include/uapi/linux/elf.h
>>>>> +++ b/include/uapi/linux/elf.h
>>>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>>>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>>>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>>>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>>>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>>>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>>>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>>>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>>>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>>>>
>>>> This is a really terrible name, "MISC".
>>>>
>>>> Having said that, I guess it's accurate. We have a whole bunch of regs that
>>>> have accrued over recent years that aren't accessible via ptrace.
>>>>
>>>> It seems to me if we're adding a misc regset we should be adding everything we
>>>> might want to it that is currenty architected.
>>>
>>> But I believe they also need to be part of the thread_struct structure to be
>>> accessible from ptrace.
>>
>> Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
>> during the process context switch. So the values of PMC1..PMC6 are not
>> thread specific in the structure. To be able to access them in ptrace
>> when the tracee has stopped, we need to context save these counters
>> in the thread struct. Shall we do that ? Then we can add them to the
>> MISC regset bucket irrespective of whats the value we get in there when
>> we probe through ptrace.
>>
>> The same goes for MMCRA, CFAR registers as well.
>>
>>>
>>>>
>>>> But currently you only include the PPR, TAR & DSCR.
>>>
>>> Yeah, thats what we started with.
>>>
>>>>
>>>> Looking at Power ISA v2.07, I see the following that could be included:
>>>>
>>>> MMCR2
>>>> MMCRA
>>>> PMC1
>>>> PMC2
>>>> PMC3
>>>> PMC4
>>>> PMC5
>>>> PMC6
>>>> MMCR0
>>>> EBBHR
>>>> EBBRR
>>>> BESCR
>>>> SIAR
>>>> SDAR
>>>> CFAR?
>>>
>>> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
>>
>> Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
>>
>>>
>>>>
>>>> Those are all new in 2.07 except for CFAR.
>>>>
>>>> There might be more I missed, that was just a quick scan.
>>>>
>>>> Some are only accessible when EBB is in use, maybe those could be a separate
>>>> regset.
>>>
>>> Yeah we can have one more regset for EBB specific registers.
>>
>> Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
>> or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
>> was thinking about putting these five registers into the MISC bucket instead.
>> But from the perf code, it looks like these five registers are also related to
>> the EBB context as well.
>>
>> Some clarity on these points would really help.
>
> Hi,
>
> from the provided testcase using ptrace interface, reviewing with the help
> of Ulrich, it looks OK from GDB perspective, with the exception of a few
> concerns:
>
> The patchset seems to change the "original" ptrace requests (i.e.
> PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" state, and
> adds new register sets to return the "checkpointed" state. Considering that
> whenever you get a debugger interception inside a transactional block, the
> transaction will abort, we're wondering if it wouldn't make more sense to
> display the 'checkpointed' state as the normal registers since this is where the
> execution will continue from.
Debugger interception (trace interrupt) in between any transaction block will abort
it ? I doubt that. The tracee process will just stop, it's context gets saved in the
kernel so that it can again start executing from the exact same point onward when it
resumes. If this happens when inside any transaction block, the transaction's running
context and check pointed context will get saved. The execution will again start from
the running context values instead of check pointed when the process resumes. Check
pointed values will be loaded back into the context when the transaction finishes.
Inside transaction both running and check pointed values can be probed independently.
>
> Also, we've noticed that the 'misc' regset contains registers from different ISA
> versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
> there is a way to detect presence/validity of such registers, but perhaps it
> might be a good idea to separate registers from different ISAs in different
> regsets.
Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we are v2.07
compliant) to detect whether TAR register is available or not.
>
> Regarding the inclusion of other registers along with the EBB-related ones, I'm
> sorry but I'm not familiar with them.
Michael Ellerman mentioned that we can look into them separately sometime later
not in this patch series.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-01-01 8:08 ` Anshuman Khandual
@ 2015-01-14 4:44 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-01-14 4:44 UTC (permalink / raw)
To: Edjunior Barbosa Machado, Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves,
Ulrich Weigand, shuahkh, akpm, oleg, dhowells, kirjanov, davej,
tglx, sukadev, davem, sam.bobroff
On 01/01/2015 01:38 PM, Anshuman Khandual wrote:
>> > Also, we've noticed that the 'misc' regset contains registers from different ISA
>> > versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
>> > there is a way to detect presence/validity of such registers, but perhaps it
>> > might be a good idea to separate registers from different ISAs in different
>> > regsets.
> Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we are v2.07
> compliant) to detect whether TAR register is available or not.
>
Need to correct something here. Run time detection of the presence of TAR register
through the feature bit CPU_FTR_ARCH_207S as I had mentioned before is not required.
Right now we take care of the compile time availability of the individual registers
the same way it is present on the thread struct. In the systems which do not have the
TAR register, thread.tar is always going to be 0 which is exactly the same value we
would get by excluding tar register copy after the run time detection of the feature.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-01-14 4:44 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-01-14 4:44 UTC (permalink / raw)
To: Edjunior Barbosa Machado, Michael Ellerman, linux-kernel, linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, davem, peterz, palves,
Ulrich Weigand, shuahkh, oleg, dhowells, kirjanov, davej, akpm,
sukadev, tglx, sam.bobroff
On 01/01/2015 01:38 PM, Anshuman Khandual wrote:
>> > Also, we've noticed that the 'misc' regset contains registers from different ISA
>> > versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
>> > there is a way to detect presence/validity of such registers, but perhaps it
>> > might be a good idea to separate registers from different ISAs in different
>> > regsets.
> Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we are v2.07
> compliant) to detect whether TAR register is available or not.
>
Need to correct something here. Run time detection of the presence of TAR register
through the feature bit CPU_FTR_ARCH_207S as I had mentioned before is not required.
Right now we take care of the compile time availability of the individual registers
the same way it is present on the thread struct. In the systems which do not have the
TAR register, thread.tar is always going to be 0 which is exactly the same value we
would get by excluding tar register copy after the run time detection of the feature.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-01-01 8:08 ` Anshuman Khandual
@ 2015-01-21 23:39 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-01-21 23:39 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Edjunior Barbosa Machado, Michael Ellerman, linux-kernel,
linuxppc-dev, james.hogan, avagin, Paul.Clothier, peterz, palves,
Ulrich Weigand, shuahkh, akpm, oleg, dhowells, kirjanov, davej,
tglx, sukadev, davem, sam.bobroff
On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
> On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> > On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
> >> On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
> >>> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
> >>>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
> >>>>> This patch adds four new ELF core note sections for powerpc
> >>>>> transactional memory and one new ELF core note section for
> >>>>> powerpc general miscellaneous debug registers. These addition
> >>>>> of new ELF core note sections extends the existing ELF ABI
> >>>>> without affecting it in any manner.
> >>>>>
> >>>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
> >>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> >>>>> ---
> >>>>> include/uapi/linux/elf.h | 5 +++++
> >>>>> 1 file changed, 5 insertions(+)
> >>>>>
> >>>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> >>>>> index ea9bf25..2260fc0 100644
> >>>>> --- a/include/uapi/linux/elf.h
> >>>>> +++ b/include/uapi/linux/elf.h
> >>>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
> >>>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
> >>>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
> >>>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
> >>>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
> >>>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
> >>>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
> >>>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
> >>>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
> >>>>
> >>>> This is a really terrible name, "MISC".
> >>>>
> >>>> Having said that, I guess it's accurate. We have a whole bunch of regs that
> >>>> have accrued over recent years that aren't accessible via ptrace.
> >>>>
> >>>> It seems to me if we're adding a misc regset we should be adding everything we
> >>>> might want to it that is currenty architected.
> >>>
> >>> But I believe they also need to be part of the thread_struct structure to be
> >>> accessible from ptrace.
> >>
> >> Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
> >> during the process context switch. So the values of PMC1..PMC6 are not
> >> thread specific in the structure. To be able to access them in ptrace
> >> when the tracee has stopped, we need to context save these counters
> >> in the thread struct. Shall we do that ? Then we can add them to the
> >> MISC regset bucket irrespective of whats the value we get in there when
> >> we probe through ptrace.
> >>
> >> The same goes for MMCRA, CFAR registers as well.
> >>
> >>>
> >>>>
> >>>> But currently you only include the PPR, TAR & DSCR.
> >>>
> >>> Yeah, thats what we started with.
> >>>
> >>>>
> >>>> Looking at Power ISA v2.07, I see the following that could be included:
> >>>>
> >>>> MMCR2
> >>>> MMCRA
> >>>> PMC1
> >>>> PMC2
> >>>> PMC3
> >>>> PMC4
> >>>> PMC5
> >>>> PMC6
> >>>> MMCR0
> >>>> EBBHR
> >>>> EBBRR
> >>>> BESCR
> >>>> SIAR
> >>>> SDAR
> >>>> CFAR?
> >>>
> >>> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
> >>
> >> Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
> >>
> >>>
> >>>>
> >>>> Those are all new in 2.07 except for CFAR.
> >>>>
> >>>> There might be more I missed, that was just a quick scan.
> >>>>
> >>>> Some are only accessible when EBB is in use, maybe those could be a separate
> >>>> regset.
> >>>
> >>> Yeah we can have one more regset for EBB specific registers.
> >>
> >> Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
> >> or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
> >> was thinking about putting these five registers into the MISC bucket instead.
> >> But from the perf code, it looks like these five registers are also related to
> >> the EBB context as well.
> >>
> >> Some clarity on these points would really help.
> >
> > Hi,
> >
> > from the provided testcase using ptrace interface, reviewing with the help
> > of Ulrich, it looks OK from GDB perspective, with the exception of a few
> > concerns:
> >
> > The patchset seems to change the "original" ptrace requests (i.e.
> > PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" state, and
> > adds new register sets to return the "checkpointed" state. Considering that
> > whenever you get a debugger interception inside a transactional block, the
> > transaction will abort, we're wondering if it wouldn't make more sense to
> > display the 'checkpointed' state as the normal registers since this is where the
> > execution will continue from.
>
> Debugger interception (trace interrupt) in between any transaction block will abort
> it ? I doubt that.
The trace interrupt will not abort the transaction explicitly...
> The tracee process will just stop, it's context gets saved in the
> kernel so that it can again start executing from the exact same point onward when it
> resumes.
... unfortunately, this save *will* doom the transaction. To save, a
treclaim instruction is run which will always explicitly doom the
transaction.
> If this happens when inside any transaction block, the transaction's running
> context and check pointed context will get saved. The execution will again start from
> the running context values instead of check pointed when the process resumes. Check
> pointed values will be loaded back into the context when the transaction finishes.
Although since the transaction has been explicitly doomed, the hardware
will *always* abort at this point and start execution from the
checkpointed values.
> Inside transaction both running and check pointed values can be probed independently.
Yep, that's the idea, although setting the running values won't change
anything since the the translation is already doomed and will abort once
the cpu starts executing it.
Mikey
> >
> > Also, we've noticed that the 'misc' regset contains registers from different ISA
> > versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
> > there is a way to detect presence/validity of such registers, but perhaps it
> > might be a good idea to separate registers from different ISAs in different
> > regsets.
>
> Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we are v2.07
> compliant) to detect whether TAR register is available or not.
>
> >
> > Regarding the inclusion of other registers along with the EBB-related ones, I'm
> > sorry but I'm not familiar with them.
>
> Michael Ellerman mentioned that we can look into them separately sometime later
> not in this patch series.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-01-21 23:39 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-01-21 23:39 UTC (permalink / raw)
To: Anshuman Khandual
Cc: james.hogan, avagin, Paul.Clothier, davem, peterz,
Ulrich Weigand, oleg, linux-kernel, shuahkh, dhowells,
linuxppc-dev, kirjanov, tglx, palves, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
> On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> > On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
> >> On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
> >>> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
> >>>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
> >>>>> This patch adds four new ELF core note sections for powerpc
> >>>>> transactional memory and one new ELF core note section for
> >>>>> powerpc general miscellaneous debug registers. These addition
> >>>>> of new ELF core note sections extends the existing ELF ABI
> >>>>> without affecting it in any manner.
> >>>>>
> >>>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
> >>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> >>>>> ---
> >>>>> include/uapi/linux/elf.h | 5 +++++
> >>>>> 1 file changed, 5 insertions(+)
> >>>>>
> >>>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> >>>>> index ea9bf25..2260fc0 100644
> >>>>> --- a/include/uapi/linux/elf.h
> >>>>> +++ b/include/uapi/linux/elf.h
> >>>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
> >>>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
> >>>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
> >>>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
> >>>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
> >>>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
> >>>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
> >>>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
> >>>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
> >>>>
> >>>> This is a really terrible name, "MISC".
> >>>>
> >>>> Having said that, I guess it's accurate. We have a whole bunch of re=
gs that
> >>>> have accrued over recent years that aren't accessible via ptrace.
> >>>>
> >>>> It seems to me if we're adding a misc regset we should be adding eve=
rything we
> >>>> might want to it that is currenty architected.
> >>>
> >>> But I believe they also need to be part of the thread_struct structur=
e to be
> >>> accessible from ptrace.
> >>
> >> Currently we dont context save/restore the PMC count registers (PMC1-P=
MC6)
> >> during the process context switch. So the values of PMC1..PMC6 are not
> >> thread specific in the structure. To be able to access them in ptrace
> >> when the tracee has stopped, we need to context save these counters
> >> in the thread struct. Shall we do that ? Then we can add them to the
> >> MISC regset bucket irrespective of whats the value we get in there whe=
n
> >> we probe through ptrace.
> >>
> >> The same goes for MMCRA, CFAR registers as well.
> >>
> >>> =20
> >>>>
> >>>> But currently you only include the PPR, TAR & DSCR.
> >>>
> >>> Yeah, thats what we started with.
> >>>
> >>>>
> >>>> Looking at Power ISA v2.07, I see the following that could be includ=
ed:
> >>>>
> >>>> MMCR2
> >>>> MMCRA
> >>>> PMC1
> >>>> PMC2
> >>>> PMC3
> >>>> PMC4
> >>>> PMC5
> >>>> PMC6
> >>>> MMCR0
> >>>> EBBHR
> >>>> EBBRR
> >>>> BESCR
> >>>> SIAR
> >>>> SDAR
> >>>> CFAR?
> >>>
> >>> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the threa=
d struct.
> >>
> >> Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
> >>
> >>>
> >>>>
> >>>> Those are all new in 2.07 except for CFAR.
> >>>>
> >>>> There might be more I missed, that was just a quick scan.
> >>>>
> >>>> Some are only accessible when EBB is in use, maybe those could be a =
separate
> >>>> regset.
> >>>
> >>> Yeah we can have one more regset for EBB specific registers.
> >>
> >> Should the new EBB specific regset include only EBBRR, EBBHR, BESCR re=
gisters
> >> or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as =
well. I
> >> was thinking about putting these five registers into the MISC bucket i=
nstead.
> >> But from the perf code, it looks like these five registers are also re=
lated to
> >> the EBB context as well.
> >>
> >> Some clarity on these points would really help.
> >=20
> > Hi,
> >=20
> > from the provided testcase using ptrace interface, reviewing with the h=
elp
> > of Ulrich, it looks OK from GDB perspective, with the exception of a fe=
w
> > concerns:
> >=20
> > The patchset seems to change the "original" ptrace requests (i.e.
> > PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" st=
ate, and
> > adds new register sets to return the "checkpointed" state. Considering =
that
> > whenever you get a debugger interception inside a transactional block, =
the
> > transaction will abort, we're wondering if it wouldn't make more sense =
to=20
> > display the 'checkpointed' state as the normal registers since this is =
where the
> > execution will continue from.
>=20
> Debugger interception (trace interrupt) in between any transaction block =
will abort
> it ? I doubt that.
The trace interrupt will not abort the transaction explicitly...
> The tracee process will just stop, it's context gets saved in the
> kernel so that it can again start executing from the exact same point onw=
ard when it
> resumes.=20
... unfortunately, this save *will* doom the transaction. To save, a
treclaim instruction is run which will always explicitly doom the
transaction.
> If this happens when inside any transaction block, the transaction's runn=
ing
> context and check pointed context will get saved. The execution will agai=
n start from
> the running context values instead of check pointed when the process resu=
mes. Check
> pointed values will be loaded back into the context when the transaction =
finishes.
Although since the transaction has been explicitly doomed, the hardware
will *always* abort at this point and start execution from the
checkpointed values.
> Inside transaction both running and check pointed values can be probed in=
dependently.
Yep, that's the idea, although setting the running values won't change
anything since the the translation is already doomed and will abort once
the cpu starts executing it. =20
Mikey
> >=20
> > Also, we've noticed that the 'misc' regset contains registers from diff=
erent ISA
> > versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not s=
ure if
> > there is a way to detect presence/validity of such registers, but perha=
ps it
> > might be a good idea to separate registers from different ISAs in diffe=
rent
> > regsets.
>=20
> Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we =
are v2.07
> compliant) to detect whether TAR register is available or not.=20
>=20
> >=20
> > Regarding the inclusion of other registers along with the EBB-related o=
nes, I'm
> > sorry but I'm not familiar with them.
>=20
> Michael Ellerman mentioned that we can look into them separately sometime=
later
> not in this patch series.
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-01-21 23:39 ` Michael Neuling
@ 2015-01-22 15:55 ` Ulrich Weigand
-1 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-01-22 15:55 UTC (permalink / raw)
To: Michael Neuling
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
Michael Neuling <mikey@neuling.org> wrote on 22.01.2015 00:39:57:
> On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
> > On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> > > The patchset seems to change the "original" ptrace requests (i.e.
> > > PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the
> > > "transactional" state, and adds new register sets to return
> > > the "checkpointed" state. Considering that whenever you get
> > > a debugger interception inside a transactional block, the
> > > transaction will abort, we're wondering if it wouldn't make
> > > more sense to display the 'checkpointed' state as the normal
> > > registers since this is where the execution will continue from.
> >
> > Debugger interception (trace interrupt) in between any transaction
> > block will abort it ? I doubt that.
>
> The trace interrupt will not abort the transaction explicitly...
>
> > The tracee process will just stop, it's context gets saved in the
> > kernel so that it can again start executing from the exact same
> > point onward when it resumes.
>
> ... unfortunately, this save *will* doom the transaction. To save, a
> treclaim instruction is run which will always explicitly doom the
> transaction.
>
> > If this happens when inside any transaction block, the transaction's
running
> > context and check pointed context will get saved. The execution
> > will again start from the running context values instead of check
> > pointed when the process resumes. Check pointed values will be loaded
> > back into the context when the transaction finishes.
>
> Although since the transaction has been explicitly doomed, the hardware
> will *always* abort at this point and start execution from the
> checkpointed values.
>
> > Inside transaction both running and check pointed values can be
> > probed independently.
>
> Yep, that's the idea, although setting the running values won't change
> anything since the the translation is already doomed and will abort once
> the cpu starts executing it.
So this looks to me like the overall effect on debugging transactional
code should be the same on Power and z, even if some internal details
are different (on z, the exception will automatically abort the
transaction; on p, the exception itself will not abort, but *restarting*
user space execution will).
>From a GDB perspective, it would therefore be preferable if the ptrace
interface were to behave in a similar fashion on p as on z: that is,
if an exception interrupting a transaction results in a ptrace intercept,
at this point:
- the "normal" ptrace register set commands should access the
*checkpointed* registers (allowing both read and write access)
-- GDB will use this to display current position (already reflecting
the fact that the transaction will abort), and use it when changing
register values e.g. to effect an inferior function call
- a new ptrace register set should allow access (read-only) to the
*running* register values
-- GDB can use this to display the position inside the transaction
at the point it aborted, using new transaction-specific commands
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-01-22 15:55 ` Ulrich Weigand
0 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-01-22 15:55 UTC (permalink / raw)
To: Michael Neuling
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
Michael Neuling <mikey@neuling.org> wrote on 22.01.2015 00:39:57:
> On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
> > On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> > > The patchset seems to change the "original" ptrace requests (i.e.
> > > PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the
> > > "transactional" state, and adds new register sets to return
> > > the "checkpointed" state. Considering that whenever you get
> > > a debugger interception inside a transactional block, the
> > > transaction will abort, we're wondering if it wouldn't make
> > > more sense to display the 'checkpointed' state as the normal
> > > registers since this is where the execution will continue from.
> >
> > Debugger interception (trace interrupt) in between any transaction
> > block will abort it ? I doubt that.
>
> The trace interrupt will not abort the transaction explicitly...
>
> > The tracee process will just stop, it's context gets saved in the
> > kernel so that it can again start executing from the exact same
> > point onward when it resumes.
>
> ... unfortunately, this save *will* doom the transaction. To save, a
> treclaim instruction is run which will always explicitly doom the
> transaction.
>
> > If this happens when inside any transaction block, the transaction's
running
> > context and check pointed context will get saved. The execution
> > will again start from the running context values instead of check
> > pointed when the process resumes. Check pointed values will be loaded
> > back into the context when the transaction finishes.
>
> Although since the transaction has been explicitly doomed, the hardware
> will *always* abort at this point and start execution from the
> checkpointed values.
>
> > Inside transaction both running and check pointed values can be
> > probed independently.
>
> Yep, that's the idea, although setting the running values won't change
> anything since the the translation is already doomed and will abort once
> the cpu starts executing it.
So this looks to me like the overall effect on debugging transactional
code should be the same on Power and z, even if some internal details
are different (on z, the exception will automatically abort the
transaction; on p, the exception itself will not abort, but *restarting*
user space execution will).
>From a GDB perspective, it would therefore be preferable if the ptrace
interface were to behave in a similar fashion on p as on z: that is,
if an exception interrupting a transaction results in a ptrace intercept,
at this point:
- the "normal" ptrace register set commands should access the
*checkpointed* registers (allowing both read and write access)
-- GDB will use this to display current position (already reflecting
the fact that the transaction will abort), and use it when changing
register values e.g. to effect an inferior function call
- a new ptrace register set should allow access (read-only) to the
*running* register values
-- GDB can use this to display the position inside the transaction
at the point it aborted, using new transaction-specific commands
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-01-22 15:55 ` Ulrich Weigand
@ 2015-01-22 21:44 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-01-22 21:44 UTC (permalink / raw)
To: Ulrich Weigand
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
> > > Inside transaction both running and check pointed values can be
> > > probed independently.
> >
> > Yep, that's the idea, although setting the running values won't change
> > anything since the the translation is already doomed and will abort once
> > the cpu starts executing it.
>
> So this looks to me like the overall effect on debugging transactional
> code should be the same on Power and z, even if some internal details
> are different (on z, the exception will automatically abort the
> transaction; on p, the exception itself will not abort, but *restarting*
> user space execution will).
Yep
> From a GDB perspective, it would therefore be preferable if the ptrace
> interface were to behave in a similar fashion on p as on z: that is,
> if an exception interrupting a transaction results in a ptrace intercept,
> at this point:
Agreed.
> - the "normal" ptrace register set commands should access the
> *checkpointed* registers (allowing both read and write access)
OK, this is a change from what we've been proposing with Anshuman's
patch set but I'm happy to change it to make it consistent with other
architectures. It's relatively arbitrary which goes where, so I'm happy
to change.
> -- GDB will use this to display current position (already reflecting
> the fact that the transaction will abort), and use it when changing
> register values e.g. to effect an inferior function call
"Current position" depends on your perspective. Is it the last executed
instruction or the next executed instruction? If it's the last executed
instruction, then it's the running values. If it's the next, then it's
the check pointed.
Anyway, I'm happy to make it the check pointed values for the sake of
ptrace/gdb.
> - a new ptrace register set should allow access (read-only) to the
> *running* register values
This is because changing them won't ever result in a side effect?
> -- GDB can use this to display the position inside the transaction
> at the point it aborted, using new transaction-specific commands
Yep.
Mikey
PS in the subject s/specifc/specific/
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-01-22 21:44 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-01-22 21:44 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
> > > Inside transaction both running and check pointed values can be
> > > probed independently.
> >
> > Yep, that's the idea, although setting the running values won't change
> > anything since the the translation is already doomed and will abort onc=
e
> > the cpu starts executing it.
>=20
> So this looks to me like the overall effect on debugging transactional
> code should be the same on Power and z, even if some internal details
> are different (on z, the exception will automatically abort the
> transaction; on p, the exception itself will not abort, but *restarting*
> user space execution will).
Yep
> From a GDB perspective, it would therefore be preferable if the ptrace
> interface were to behave in a similar fashion on p as on z: that is,
> if an exception interrupting a transaction results in a ptrace intercept,
> at this point:
Agreed.
> - the "normal" ptrace register set commands should access the
> *checkpointed* registers (allowing both read and write access)
OK, this is a change from what we've been proposing with Anshuman's
patch set but I'm happy to change it to make it consistent with other
architectures. It's relatively arbitrary which goes where, so I'm happy
to change.
> -- GDB will use this to display current position (already reflecting
> the fact that the transaction will abort), and use it when changing
> register values e.g. to effect an inferior function call
"Current position" depends on your perspective. Is it the last executed
instruction or the next executed instruction? If it's the last executed
instruction, then it's the running values. If it's the next, then it's
the check pointed. =20
Anyway, I'm happy to make it the check pointed values for the sake of
ptrace/gdb.
> - a new ptrace register set should allow access (read-only) to the
> *running* register values
This is because changing them won't ever result in a side effect? =20
> -- GDB can use this to display the position inside the transaction
> at the point it aborted, using new transaction-specific commands
Yep.
Mikey
PS in the subject s/specifc/specific/
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-01-22 21:44 ` Michael Neuling
@ 2015-01-28 4:28 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-01-28 4:28 UTC (permalink / raw)
To: Ulrich Weigand
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
On Fri, 2015-01-23 at 08:44 +1100, Michael Neuling wrote:
> > > > Inside transaction both running and check pointed values can be
> > > > probed independently.
> > >
> > > Yep, that's the idea, although setting the running values won't change
> > > anything since the the translation is already doomed and will abort once
> > > the cpu starts executing it.
> >
> > So this looks to me like the overall effect on debugging transactional
> > code should be the same on Power and z, even if some internal details
> > are different (on z, the exception will automatically abort the
> > transaction; on p, the exception itself will not abort, but *restarting*
> > user space execution will).
>
> Yep
>
> > From a GDB perspective, it would therefore be preferable if the ptrace
> > interface were to behave in a similar fashion on p as on z: that is,
> > if an exception interrupting a transaction results in a ptrace intercept,
> > at this point:
>
> Agreed.
>
> > - the "normal" ptrace register set commands should access the
> > *checkpointed* registers (allowing both read and write access)
>
> OK, this is a change from what we've been proposing with Anshuman's
> patch set but I'm happy to change it to make it consistent with other
> architectures. It's relatively arbitrary which goes where, so I'm happy
> to change.
>
> > -- GDB will use this to display current position (already reflecting
> > the fact that the transaction will abort), and use it when changing
> > register values e.g. to effect an inferior function call
>
> "Current position" depends on your perspective. Is it the last executed
> instruction or the next executed instruction? If it's the last executed
> instruction, then it's the running values. If it's the next, then it's
> the check pointed.
>
> Anyway, I'm happy to make it the check pointed values for the sake of
> ptrace/gdb.
Uli,
Sorry, I'm rethinking this as we didn't consider user suspended
transactions.
It makes sense for normal transactions but for user suspended
transactions the running values are the ones you want to modify since
that is where you'll end up restarting from. The hardware will only
abort/rollback once a tresume is encountered.
*
So we could do what you're talking about for normal transactions and
then switch them for suspended transactions. But this just seems to be
making the kernel interface overly complicated.
So I'm keen on just keeping it the way Anshuman has now and GDB has to
understand the program flow better to know which ones it wants to
modify. The kernel always provides the "normal" set as running and the
new set as check pointed. GDB then has to check the MSR to work out
what it wants to modify.
> > - a new ptrace register set should allow access (read-only) to the
> > *running* register values
>
> This is because changing them won't ever result in a side effect?
For the same reason as above, we need to be able to modify the running
values when it's a user suspended transaction. So I don't agree with
this any more in the case of user suspended transaction. We need to be
able to modify both sets of registers.
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-01-28 4:28 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-01-28 4:28 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
On Fri, 2015-01-23 at 08:44 +1100, Michael Neuling wrote:
> > > > Inside transaction both running and check pointed values can be
> > > > probed independently.
> > >
> > > Yep, that's the idea, although setting the running values won't chang=
e
> > > anything since the the translation is already doomed and will abort o=
nce
> > > the cpu starts executing it.
> >=20
> > So this looks to me like the overall effect on debugging transactional
> > code should be the same on Power and z, even if some internal details
> > are different (on z, the exception will automatically abort the
> > transaction; on p, the exception itself will not abort, but *restarting=
*
> > user space execution will).
>=20
> Yep
>=20
> > From a GDB perspective, it would therefore be preferable if the ptrace
> > interface were to behave in a similar fashion on p as on z: that is,
> > if an exception interrupting a transaction results in a ptrace intercep=
t,
> > at this point:
>=20
> Agreed.
>=20
> > - the "normal" ptrace register set commands should access the
> > *checkpointed* registers (allowing both read and write access)
>=20
> OK, this is a change from what we've been proposing with Anshuman's
> patch set but I'm happy to change it to make it consistent with other
> architectures. It's relatively arbitrary which goes where, so I'm happy
> to change.
>=20
> > -- GDB will use this to display current position (already reflecting
> > the fact that the transaction will abort), and use it when changing
> > register values e.g. to effect an inferior function call
>=20
> "Current position" depends on your perspective. Is it the last executed
> instruction or the next executed instruction? If it's the last executed
> instruction, then it's the running values. If it's the next, then it's
> the check pointed. =20
>=20
> Anyway, I'm happy to make it the check pointed values for the sake of
> ptrace/gdb.
Uli,
Sorry, I'm rethinking this as we didn't consider user suspended
transactions.
It makes sense for normal transactions but for user suspended
transactions the running values are the ones you want to modify since
that is where you'll end up restarting from. The hardware will only
abort/rollback once a tresume is encountered.
*=20
So we could do what you're talking about for normal transactions and
then switch them for suspended transactions. But this just seems to be
making the kernel interface overly complicated. =20
So I'm keen on just keeping it the way Anshuman has now and GDB has to
understand the program flow better to know which ones it wants to
modify. The kernel always provides the "normal" set as running and the
new set as check pointed. GDB then has to check the MSR to work out
what it wants to modify.
> > - a new ptrace register set should allow access (read-only) to the
> > *running* register values
>=20
> This is because changing them won't ever result in a side effect? =20
For the same reason as above, we need to be able to modify the running
values when it's a user suspended transaction. So I don't agree with
this any more in the case of user suspended transaction. We need to be
able to modify both sets of registers.
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-01-28 4:28 ` Michael Neuling
@ 2015-02-06 14:47 ` Ulrich Weigand
-1 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-02-06 14:47 UTC (permalink / raw)
To: Michael Neuling
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
Michael Neuling <mikey@neuling.org> wrote on 28.01.2015 05:28:09:
> Sorry, I'm rethinking this as we didn't consider user suspended
> transactions.
>
> It makes sense for normal transactions but for user suspended
> transactions the running values are the ones you want to modify since
> that is where you'll end up restarting from. The hardware will only
> abort/rollback once a tresume is encountered.
OK, I see. I hadn't really looked into suspended transactions before ...
> So we could do what you're talking about for normal transactions and
> then switch them for suspended transactions. But this just seems to be
> making the kernel interface overly complicated.
Agreed. Given that there seems to be an inevitable difference in how
transactions are seen by the debugger between Power and z (there are
no suspended transactions on z), I guess it makes more sense to have
the interface naturally model the hardware register sets on Power,
and have GDB cope with the differences.
> So I'm keen on just keeping it the way Anshuman has now and GDB has to
> understand the program flow better to know which ones it wants to
> modify. The kernel always provides the "normal" set as running and the
> new set as check pointed. GDB then has to check the MSR to work out
> what it wants to modify.
So I'm thinking how this all would work out for the case of GDB wanting
to call an inferior function while the process is stopped within a
transaction (in either transactional or suspended state).
(A) In suspended state, I guess GDB could modify the "normal" register
set and ask the kernel to continue. The kernel would then transfer
control to the inferior function entry point while still in suspended
state, and the inferior function would execute in suspended state until
it hits the GDB-placed breakpoint at the end. At this point, GDB would
reload the original values to the "normal" register set, and ask the
kernel to continue. The kernel would then transfer control to the
originally-interrupted piece of code in suspended state, which would
continue to execute until the tresume, at which point the transaction
would abort (due to TDOOMED). Right?
(B) In transactional state, GDB could modify the "checkpointed" register
set and ask the kernel to continue. The kernel would transfer control
to the originally-interrupted code in transactional state. At this
point, the transaction would immediately abort, and control would
transfer to the state specified in the checkpointed register set,
and the inferior function would now execute in non-transactional
state, until it hits the breakpoint. At this point, GDB would now
have to restore the original values of the *checkpointed* register
set into the *normal* register set (a bit weird from a GDB internals
perspective), and ask the kernel to continue. Execution would now
resume at the abort handler of the originally interrupted transaction.
(Hmm. Maybe GDB would also have to set cr0 or something?)
Is it possible for GDB to change the state (transactional vs.
suspended) where the kernel ought to let the application continue in?
I guess via modifying the appropriate MSR bits via ptrace?
If so, there would be other options to handle this:
(A') In the transactional state, GDB could set the MSR to suspended,
and modify the "normal" register set. The inferior function would
execute in the suspended state as in (A) above. Upon return, GDB
would restore the normal register set (including restoring the MSR
to transactional state). Once the kernel resumes the application,
the transaction would abort at this point.
(B') In the suspended state, GDB could set the MSR to transactional,
and modify the "checkpointed" register set. Once the kernel resumes
the application, the transaction immediately aborts and control
transfers to the inferior function, executing in nontransactional
state as in (B). Upon return, GDB would again need to restore the
original checkpointed register set into the normal register set,
set cr0 to indicate transactional abort, and continue.
Using the combination of (A)+(A') would be easiest to implement
in GDB without modifying a lot of common code, and would have the
advantage that the inferior function always executes in the same
state (suspended), while leaving information about the interrupted
transaction visible.
Using the combination of (B)+(B') would be a bit more difficult
to implement (but certainly feasible), and would have the advantage
that the inferior function always executes in nontransactional state
(which is what it would most likely expect, anyway). However, the
disadvantage is that after the inferior call returns, GDB is unable
to fully restore the visible inferior state as it was before (since
we're now in nontransactional state, and there is probably no way
to force us back into transactional/suspended state ...).
Am I missing something here? Any additional thoughts?
> > > - a new ptrace register set should allow access (read-only) to the
> > > *running* register values
> >
> > This is because changing them won't ever result in a side effect?
>
> For the same reason as above, we need to be able to modify the running
> values when it's a user suspended transaction. So I don't agree with
> this any more in the case of user suspended transaction. We need to be
> able to modify both sets of registers.
So I guess the kernel, on resuming the application, first loads the
checkpointed register set into normal registers, issues the trechkpt
instruction to move them to the checkpointed register, and then loads
the normal register set, before returning to user space? Then it does
indeed appear that both sets *are* modifyable, and thus the kernel
interface should export them as such.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-02-06 14:47 ` Ulrich Weigand
0 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-02-06 14:47 UTC (permalink / raw)
To: Michael Neuling
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
Michael Neuling <mikey@neuling.org> wrote on 28.01.2015 05:28:09:
> Sorry, I'm rethinking this as we didn't consider user suspended
> transactions.
>
> It makes sense for normal transactions but for user suspended
> transactions the running values are the ones you want to modify since
> that is where you'll end up restarting from. The hardware will only
> abort/rollback once a tresume is encountered.
OK, I see. I hadn't really looked into suspended transactions before ...
> So we could do what you're talking about for normal transactions and
> then switch them for suspended transactions. But this just seems to be
> making the kernel interface overly complicated.
Agreed. Given that there seems to be an inevitable difference in how
transactions are seen by the debugger between Power and z (there are
no suspended transactions on z), I guess it makes more sense to have
the interface naturally model the hardware register sets on Power,
and have GDB cope with the differences.
> So I'm keen on just keeping it the way Anshuman has now and GDB has to
> understand the program flow better to know which ones it wants to
> modify. The kernel always provides the "normal" set as running and the
> new set as check pointed. GDB then has to check the MSR to work out
> what it wants to modify.
So I'm thinking how this all would work out for the case of GDB wanting
to call an inferior function while the process is stopped within a
transaction (in either transactional or suspended state).
(A) In suspended state, I guess GDB could modify the "normal" register
set and ask the kernel to continue. The kernel would then transfer
control to the inferior function entry point while still in suspended
state, and the inferior function would execute in suspended state until
it hits the GDB-placed breakpoint at the end. At this point, GDB would
reload the original values to the "normal" register set, and ask the
kernel to continue. The kernel would then transfer control to the
originally-interrupted piece of code in suspended state, which would
continue to execute until the tresume, at which point the transaction
would abort (due to TDOOMED). Right?
(B) In transactional state, GDB could modify the "checkpointed" register
set and ask the kernel to continue. The kernel would transfer control
to the originally-interrupted code in transactional state. At this
point, the transaction would immediately abort, and control would
transfer to the state specified in the checkpointed register set,
and the inferior function would now execute in non-transactional
state, until it hits the breakpoint. At this point, GDB would now
have to restore the original values of the *checkpointed* register
set into the *normal* register set (a bit weird from a GDB internals
perspective), and ask the kernel to continue. Execution would now
resume at the abort handler of the originally interrupted transaction.
(Hmm. Maybe GDB would also have to set cr0 or something?)
Is it possible for GDB to change the state (transactional vs.
suspended) where the kernel ought to let the application continue in?
I guess via modifying the appropriate MSR bits via ptrace?
If so, there would be other options to handle this:
(A') In the transactional state, GDB could set the MSR to suspended,
and modify the "normal" register set. The inferior function would
execute in the suspended state as in (A) above. Upon return, GDB
would restore the normal register set (including restoring the MSR
to transactional state). Once the kernel resumes the application,
the transaction would abort at this point.
(B') In the suspended state, GDB could set the MSR to transactional,
and modify the "checkpointed" register set. Once the kernel resumes
the application, the transaction immediately aborts and control
transfers to the inferior function, executing in nontransactional
state as in (B). Upon return, GDB would again need to restore the
original checkpointed register set into the normal register set,
set cr0 to indicate transactional abort, and continue.
Using the combination of (A)+(A') would be easiest to implement
in GDB without modifying a lot of common code, and would have the
advantage that the inferior function always executes in the same
state (suspended), while leaving information about the interrupted
transaction visible.
Using the combination of (B)+(B') would be a bit more difficult
to implement (but certainly feasible), and would have the advantage
that the inferior function always executes in nontransactional state
(which is what it would most likely expect, anyway). However, the
disadvantage is that after the inferior call returns, GDB is unable
to fully restore the visible inferior state as it was before (since
we're now in nontransactional state, and there is probably no way
to force us back into transactional/suspended state ...).
Am I missing something here? Any additional thoughts?
> > > - a new ptrace register set should allow access (read-only) to the
> > > *running* register values
> >
> > This is because changing them won't ever result in a side effect?
>
> For the same reason as above, we need to be able to modify the running
> values when it's a user suspended transaction. So I don't agree with
> this any more in the case of user suspended transaction. We need to be
> able to modify both sets of registers.
So I guess the kernel, on resuming the application, first loads the
checkpointed register set into normal registers, issues the trechkpt
instruction to move them to the checkpointed register, and then loads
the normal register set, before returning to user space? Then it does
indeed appear that both sets *are* modifyable, and thus the kernel
interface should export them as such.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-02-06 14:47 ` Ulrich Weigand
@ 2015-02-23 4:51 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-02-23 4:51 UTC (permalink / raw)
To: Ulrich Weigand
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
Uli,
Sorry for the slow response.
> Michael Neuling <mikey@neuling.org> wrote on 28.01.2015 05:28:09:
>
> > Sorry, I'm rethinking this as we didn't consider user suspended
> > transactions.
> >
> > It makes sense for normal transactions but for user suspended
> > transactions the running values are the ones you want to modify since
> > that is where you'll end up restarting from. The hardware will only
> > abort/rollback once a tresume is encountered.
>
> OK, I see. I hadn't really looked into suspended transactions before ...
>
> > So we could do what you're talking about for normal transactions and
> > then switch them for suspended transactions. But this just seems to be
> > making the kernel interface overly complicated.
>
> Agreed. Given that there seems to be an inevitable difference in how
> transactions are seen by the debugger between Power and z (there are
> no suspended transactions on z), I guess it makes more sense to have
> the interface naturally model the hardware register sets on Power,
> and have GDB cope with the differences.
>
> > So I'm keen on just keeping it the way Anshuman has now and GDB has to
> > understand the program flow better to know which ones it wants to
> > modify. The kernel always provides the "normal" set as running and the
> > new set as check pointed. GDB then has to check the MSR to work out
> > what it wants to modify.
>
> So I'm thinking how this all would work out for the case of GDB wanting
> to call an inferior function while the process is stopped within a
> transaction (in either transactional or suspended state).
Should this inferior function be run in the current mode of the
processor? ie if the process is currently transactional and the
transaction aborts, should we be able to see any global state change
because of an inferior function being run in GDB?
Also, if you modify the stack in suspend mode, that'll be persistent.
So it's possible that you could corrupt your stack if you abort. For
example, if your tbegin is inside a function (one or more deep) that
returns (one or more times while transactional), you need make sure you
don't touch the stack non-transactionally if you want to be able to
abort and not corrupt your stack.
I think what you're proposing with running the inferior function in
suspend mode may end up corrupting the stack in this way. You'd need to
be really careful to make sure the inferior function is run on the stack
pointer of the checkpointed registers.
We do something like this in the kernel when laying out a signal frame
on the user stack when the user is transactional. We lay it out on the
checkpointed stack pointer/r1. (The best way for users to avoid this
problem is to use sigaltstack() but we can't rely on that).
> (A) In suspended state, I guess GDB could modify the "normal" register
> set and ask the kernel to continue. The kernel would then transfer
> control to the inferior function entry point while still in suspended
> state, and the inferior function would execute in suspended state until
> it hits the GDB-placed breakpoint at the end. At this point, GDB would
> reload the original values to the "normal" register set, and ask the
> kernel to continue. The kernel would then transfer control to the
> originally-interrupted piece of code in suspended state, which would
> continue to execute until the tresume, at which point the transaction
> would abort (due to TDOOMED). Right?
I think so.
> (B) In transactional state, GDB could modify the "checkpointed" register
> set and ask the kernel to continue. The kernel would transfer control
> to the originally-interrupted code in transactional state. At this
> point, the transaction would immediately abort, and control would
> transfer to the state specified in the checkpointed register set,
> and the inferior function would now execute in non-transactional
> state, until it hits the breakpoint. At this point, GDB would now
> have to restore the original values of the *checkpointed* register
> set into the *normal* register set (a bit weird from a GDB internals
> perspective), and ask the kernel to continue. Execution would now
> resume at the abort handler of the originally interrupted transaction.
> (Hmm. Maybe GDB would also have to set cr0 or something?)
OK, but do we want the inferior function to be run non-transactionally?
Should it changes be seen after the transaction aborts?
> Is it possible for GDB to change the state (transactional vs.
> suspended) where the kernel ought to let the application continue in?
> I guess via modifying the appropriate MSR bits via ptrace?
Yes, you can change the MSR to change the TM mode.
> If so, there would be other options to handle this:
>
> (A') In the transactional state, GDB could set the MSR to suspended,
> and modify the "normal" register set. The inferior function would
> execute in the suspended state as in (A) above. Upon return, GDB
> would restore the normal register set (including restoring the MSR
> to transactional state). Once the kernel resumes the application,
> the transaction would abort at this point.
This seems ok, although again, the inferior function would have side
effects even if the transaction aborts. Is that what we want? Can we
say to users that the inferior function is actually be run after the
transaction aborts?
Also, we need to be careful with the stack.
> (B') In the suspended state, GDB could set the MSR to transactional,
> and modify the "checkpointed" register set. Once the kernel resumes
> the application, the transaction immediately aborts and control
> transfers to the inferior function, executing in nontransactional
> state as in (B). Upon return, GDB would again need to restore the
> original checkpointed register set into the normal register set,
> set cr0 to indicate transactional abort, and continue.
OK.
> Using the combination of (A)+(A') would be easiest to implement
> in GDB without modifying a lot of common code, and would have the
> advantage that the inferior function always executes in the same
> state (suspended), while leaving information about the interrupted
> transaction visible.
>
> Using the combination of (B)+(B') would be a bit more difficult
> to implement (but certainly feasible), and would have the advantage
> that the inferior function always executes in nontransactional state
> (which is what it would most likely expect, anyway). However, the
> disadvantage is that after the inferior call returns, GDB is unable
> to fully restore the visible inferior state as it was before (since
> we're now in nontransactional state, and there is probably no way
> to force us back into transactional/suspended state ...).
Yep.
> Am I missing something here? Any additional thoughts?
>
> > > > - a new ptrace register set should allow access (read-only) to the
> > > > *running* register values
> > >
> > > This is because changing them won't ever result in a side effect?
> >
> > For the same reason as above, we need to be able to modify the running
> > values when it's a user suspended transaction. So I don't agree with
> > this any more in the case of user suspended transaction. We need to be
> > able to modify both sets of registers.
>
> So I guess the kernel, on resuming the application, first loads the
> checkpointed register set into normal registers, issues the trechkpt
> instruction to move them to the checkpointed register, and then loads
> the normal register set, before returning to user space?
Correct.
> Then it does
> indeed appear that both sets *are* modifyable, and thus the kernel
> interface should export them as such.
Correct.
Getting back to the kernel interface, are you happy with what Anshuman
has proposed in the current series?
Regards,
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-02-23 4:51 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-02-23 4:51 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
Uli,
Sorry for the slow response.
> Michael Neuling <mikey@neuling.org> wrote on 28.01.2015 05:28:09:
>=20
> > Sorry, I'm rethinking this as we didn't consider user suspended
> > transactions.
> >
> > It makes sense for normal transactions but for user suspended
> > transactions the running values are the ones you want to modify since
> > that is where you'll end up restarting from. The hardware will only
> > abort/rollback once a tresume is encountered.
>=20
> OK, I see. I hadn't really looked into suspended transactions before ...
>
> > So we could do what you're talking about for normal transactions and
> > then switch them for suspended transactions. But this just seems to be
> > making the kernel interface overly complicated.
>=20
> Agreed. Given that there seems to be an inevitable difference in how
> transactions are seen by the debugger between Power and z (there are
> no suspended transactions on z), I guess it makes more sense to have
> the interface naturally model the hardware register sets on Power,
> and have GDB cope with the differences.
>
> > So I'm keen on just keeping it the way Anshuman has now and GDB has to
> > understand the program flow better to know which ones it wants to
> > modify. The kernel always provides the "normal" set as running and the
> > new set as check pointed. GDB then has to check the MSR to work out
> > what it wants to modify.
>=20
> So I'm thinking how this all would work out for the case of GDB wanting
> to call an inferior function while the process is stopped within a
> transaction (in either transactional or suspended state).
Should this inferior function be run in the current mode of the
processor? ie if the process is currently transactional and the
transaction aborts, should we be able to see any global state change
because of an inferior function being run in GDB? =20
Also, if you modify the stack in suspend mode, that'll be persistent.
So it's possible that you could corrupt your stack if you abort. For
example, if your tbegin is inside a function (one or more deep) that
returns (one or more times while transactional), you need make sure you
don't touch the stack non-transactionally if you want to be able to
abort and not corrupt your stack.
I think what you're proposing with running the inferior function in
suspend mode may end up corrupting the stack in this way. You'd need to
be really careful to make sure the inferior function is run on the stack
pointer of the checkpointed registers. =20
We do something like this in the kernel when laying out a signal frame
on the user stack when the user is transactional. We lay it out on the
checkpointed stack pointer/r1. (The best way for users to avoid this
problem is to use sigaltstack() but we can't rely on that).
> (A) In suspended state, I guess GDB could modify the "normal" register
> set and ask the kernel to continue. The kernel would then transfer
> control to the inferior function entry point while still in suspended
> state, and the inferior function would execute in suspended state until
> it hits the GDB-placed breakpoint at the end. At this point, GDB would
> reload the original values to the "normal" register set, and ask the
> kernel to continue. The kernel would then transfer control to the
> originally-interrupted piece of code in suspended state, which would
> continue to execute until the tresume, at which point the transaction
> would abort (due to TDOOMED). Right?
I think so.
> (B) In transactional state, GDB could modify the "checkpointed" register
> set and ask the kernel to continue. The kernel would transfer control
> to the originally-interrupted code in transactional state. At this
> point, the transaction would immediately abort, and control would
> transfer to the state specified in the checkpointed register set,
> and the inferior function would now execute in non-transactional
> state, until it hits the breakpoint. At this point, GDB would now
> have to restore the original values of the *checkpointed* register
> set into the *normal* register set (a bit weird from a GDB internals
> perspective), and ask the kernel to continue. Execution would now
> resume at the abort handler of the originally interrupted transaction.
> (Hmm. Maybe GDB would also have to set cr0 or something?)
OK, but do we want the inferior function to be run non-transactionally?
Should it changes be seen after the transaction aborts? =20
> Is it possible for GDB to change the state (transactional vs.
> suspended) where the kernel ought to let the application continue in?
> I guess via modifying the appropriate MSR bits via ptrace?
Yes, you can change the MSR to change the TM mode.
> If so, there would be other options to handle this:
>=20
> (A') In the transactional state, GDB could set the MSR to suspended,
> and modify the "normal" register set. The inferior function would
> execute in the suspended state as in (A) above. Upon return, GDB
> would restore the normal register set (including restoring the MSR
> to transactional state). Once the kernel resumes the application,
> the transaction would abort at this point.
This seems ok, although again, the inferior function would have side
effects even if the transaction aborts. Is that what we want? Can we
say to users that the inferior function is actually be run after the
transaction aborts?
Also, we need to be careful with the stack. =20
> (B') In the suspended state, GDB could set the MSR to transactional,
> and modify the "checkpointed" register set. Once the kernel resumes
> the application, the transaction immediately aborts and control
> transfers to the inferior function, executing in nontransactional
> state as in (B). Upon return, GDB would again need to restore the
> original checkpointed register set into the normal register set,
> set cr0 to indicate transactional abort, and continue.
OK.
> Using the combination of (A)+(A') would be easiest to implement
> in GDB without modifying a lot of common code, and would have the
> advantage that the inferior function always executes in the same
> state (suspended), while leaving information about the interrupted
> transaction visible.
>=20
> Using the combination of (B)+(B') would be a bit more difficult
> to implement (but certainly feasible), and would have the advantage
> that the inferior function always executes in nontransactional state
> (which is what it would most likely expect, anyway). However, the
> disadvantage is that after the inferior call returns, GDB is unable
> to fully restore the visible inferior state as it was before (since
> we're now in nontransactional state, and there is probably no way
> to force us back into transactional/suspended state ...).
Yep.
> Am I missing something here? Any additional thoughts?
>
> > > > - a new ptrace register set should allow access (read-only) to the
> > > > *running* register values
> > >
> > > This is because changing them won't ever result in a side effect?
> >
> > For the same reason as above, we need to be able to modify the running
> > values when it's a user suspended transaction. So I don't agree with
> > this any more in the case of user suspended transaction. We need to be
> > able to modify both sets of registers.
>=20
> So I guess the kernel, on resuming the application, first loads the
> checkpointed register set into normal registers, issues the trechkpt
> instruction to move them to the checkpointed register, and then loads
> the normal register set, before returning to user space? =20
Correct.
> Then it does
> indeed appear that both sets *are* modifyable, and thus the kernel
> interface should export them as such.
Correct.
Getting back to the kernel interface, are you happy with what Anshuman
has proposed in the current series?
Regards,
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-02-23 4:51 ` Michael Neuling
@ 2015-03-18 12:53 ` Ulrich Weigand
-1 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-03-18 12:53 UTC (permalink / raw)
To: Michael Neuling
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
> Sorry for the slow response.
Same here :-(
> Should this inferior function be run in the current mode of the
> processor? ie if the process is currently transactional and the
> transaction aborts, should we be able to see any global state change
> because of an inferior function being run in GDB?
Inferior functions IMO should *not* run in transactional mode.
A typical inferior call is to malloc to get some memory to be used
by GDB to store data in the inferior ... you wouldn't want to call
malloc inside a transaction.
Now, whether inferior functions can run in *suspended* mode
(i.e. causing the transaction to abort after the inferior call
has returned) or have to run in nontransactional mode (aborting
the transaction befer the inferior call), I'm not sure. Unless
there are some unexpected side effect, it seems cleaner to run
in suspended mode, since this way we can restore the state we
were in before the inferior call after the call (which is what
user would tend to expect).
On the other hand, inferior function calls do not necessarily
return. In fact, they could throw or longjmp to some routine
higher up on the stack, in which case GDB will never get control
back. The rest of program execution would then be done in suspended
mode (and not nontransactional mode), at least until code attempts
to start the next transaction. Not sure if this is an issue.
> Also, if you modify the stack in suspend mode, that'll be persistent.
> So it's possible that you could corrupt your stack if you abort. For
> example, if your tbegin is inside a function (one or more deep) that
> returns (one or more times while transactional), you need make sure you
> don't touch the stack non-transactionally if you want to be able to
> abort and not corrupt your stack.
I see.
> I think what you're proposing with running the inferior function in
> suspend mode may end up corrupting the stack in this way. You'd need to
> be really careful to make sure the inferior function is run on the stack
> pointer of the checkpointed registers.
On the other hand, if code called a subroutine after the tbegin, if we
were using the checkpointed r1, this might corrupt the stack of the
transactional code. (This code will never actually *run* again since
the transaction is doomed, but we can still *inspect* it in GDB after
the inferior call has returned, so the stack should remain unchanged.
Well .. if the transaction is suspended, the code might in fact still
run, so it should remain unchanged either way.)
I guess we could use the minimum of transactional and checkpointed r1
in that case, to be safe either way.
> > (A) In suspended state, I guess GDB could modify the "normal" register
> > set and ask the kernel to continue. The kernel would then transfer
> > control to the inferior function entry point while still in suspended
> > state, and the inferior function would execute in suspended state until
> > it hits the GDB-placed breakpoint at the end. At this point, GDB would
> > reload the original values to the "normal" register set, and ask the
> > kernel to continue. The kernel would then transfer control to the
> > originally-interrupted piece of code in suspended state, which would
> > continue to execute until the tresume, at which point the transaction
> > would abort (due to TDOOMED). Right?
>
> I think so.
Good.
> > (B) In transactional state, GDB could modify the "checkpointed"
register
> > set and ask the kernel to continue. The kernel would transfer control
> > to the originally-interrupted code in transactional state. At this
> > point, the transaction would immediately abort, and control would
> > transfer to the state specified in the checkpointed register set,
> > and the inferior function would now execute in non-transactional
> > state, until it hits the breakpoint. At this point, GDB would now
> > have to restore the original values of the *checkpointed* register
> > set into the *normal* register set (a bit weird from a GDB internals
> > perspective), and ask the kernel to continue. Execution would now
> > resume at the abort handler of the originally interrupted transaction.
> > (Hmm. Maybe GDB would also have to set cr0 or something?)
>
> OK, but do we want the inferior function to be run non-transactionally?
> Should it changes be seen after the transaction aborts?
Yes, see above.
> > Is it possible for GDB to change the state (transactional vs.
> > suspended) where the kernel ought to let the application continue in?
> > I guess via modifying the appropriate MSR bits via ptrace?
>
> Yes, you can change the MSR to change the TM mode.
OK, that's good.
> > If so, there would be other options to handle this:
> >
> > (A') In the transactional state, GDB could set the MSR to suspended,
> > and modify the "normal" register set. The inferior function would
> > execute in the suspended state as in (A) above. Upon return, GDB
> > would restore the normal register set (including restoring the MSR
> > to transactional state). Once the kernel resumes the application,
> > the transaction would abort at this point.
>
> This seems ok, although again, the inferior function would have side
> effects even if the transaction aborts. Is that what we want? Can we
> say to users that the inferior function is actually be run after the
> transaction aborts?
>
> Also, we need to be careful with the stack.
See above.
> > (B') In the suspended state, GDB could set the MSR to transactional,
> > and modify the "checkpointed" register set. Once the kernel resumes
> > the application, the transaction immediately aborts and control
> > transfers to the inferior function, executing in nontransactional
> > state as in (B). Upon return, GDB would again need to restore the
> > original checkpointed register set into the normal register set,
> > set cr0 to indicate transactional abort, and continue.
>
> OK.
>
> > Using the combination of (A)+(A') would be easiest to implement
> > in GDB without modifying a lot of common code, and would have the
> > advantage that the inferior function always executes in the same
> > state (suspended), while leaving information about the interrupted
> > transaction visible.
> >
> > Using the combination of (B)+(B') would be a bit more difficult
> > to implement (but certainly feasible), and would have the advantage
> > that the inferior function always executes in nontransactional state
> > (which is what it would most likely expect, anyway). However, the
> > disadvantage is that after the inferior call returns, GDB is unable
> > to fully restore the visible inferior state as it was before (since
> > we're now in nontransactional state, and there is probably no way
> > to force us back into transactional/suspended state ...).
>
> Yep.
So right now I'd tend to prefer (A)+(A'), but the important thing is
that the kernel seems to provide all features required for GDB to
implement any of the above, so we can still make that decision later.
> Getting back to the kernel interface, are you happy with what Anshuman
> has proposed in the current series?
Given the discussion above, this seems fine to me now.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-03-18 12:53 ` Ulrich Weigand
0 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-03-18 12:53 UTC (permalink / raw)
To: Michael Neuling
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
> Sorry for the slow response.
Same here :-(
> Should this inferior function be run in the current mode of the
> processor? ie if the process is currently transactional and the
> transaction aborts, should we be able to see any global state change
> because of an inferior function being run in GDB?
Inferior functions IMO should *not* run in transactional mode.
A typical inferior call is to malloc to get some memory to be used
by GDB to store data in the inferior ... you wouldn't want to call
malloc inside a transaction.
Now, whether inferior functions can run in *suspended* mode
(i.e. causing the transaction to abort after the inferior call
has returned) or have to run in nontransactional mode (aborting
the transaction befer the inferior call), I'm not sure. Unless
there are some unexpected side effect, it seems cleaner to run
in suspended mode, since this way we can restore the state we
were in before the inferior call after the call (which is what
user would tend to expect).
On the other hand, inferior function calls do not necessarily
return. In fact, they could throw or longjmp to some routine
higher up on the stack, in which case GDB will never get control
back. The rest of program execution would then be done in suspended
mode (and not nontransactional mode), at least until code attempts
to start the next transaction. Not sure if this is an issue.
> Also, if you modify the stack in suspend mode, that'll be persistent.
> So it's possible that you could corrupt your stack if you abort. For
> example, if your tbegin is inside a function (one or more deep) that
> returns (one or more times while transactional), you need make sure you
> don't touch the stack non-transactionally if you want to be able to
> abort and not corrupt your stack.
I see.
> I think what you're proposing with running the inferior function in
> suspend mode may end up corrupting the stack in this way. You'd need to
> be really careful to make sure the inferior function is run on the stack
> pointer of the checkpointed registers.
On the other hand, if code called a subroutine after the tbegin, if we
were using the checkpointed r1, this might corrupt the stack of the
transactional code. (This code will never actually *run* again since
the transaction is doomed, but we can still *inspect* it in GDB after
the inferior call has returned, so the stack should remain unchanged.
Well .. if the transaction is suspended, the code might in fact still
run, so it should remain unchanged either way.)
I guess we could use the minimum of transactional and checkpointed r1
in that case, to be safe either way.
> > (A) In suspended state, I guess GDB could modify the "normal" register
> > set and ask the kernel to continue. The kernel would then transfer
> > control to the inferior function entry point while still in suspended
> > state, and the inferior function would execute in suspended state until
> > it hits the GDB-placed breakpoint at the end. At this point, GDB would
> > reload the original values to the "normal" register set, and ask the
> > kernel to continue. The kernel would then transfer control to the
> > originally-interrupted piece of code in suspended state, which would
> > continue to execute until the tresume, at which point the transaction
> > would abort (due to TDOOMED). Right?
>
> I think so.
Good.
> > (B) In transactional state, GDB could modify the "checkpointed"
register
> > set and ask the kernel to continue. The kernel would transfer control
> > to the originally-interrupted code in transactional state. At this
> > point, the transaction would immediately abort, and control would
> > transfer to the state specified in the checkpointed register set,
> > and the inferior function would now execute in non-transactional
> > state, until it hits the breakpoint. At this point, GDB would now
> > have to restore the original values of the *checkpointed* register
> > set into the *normal* register set (a bit weird from a GDB internals
> > perspective), and ask the kernel to continue. Execution would now
> > resume at the abort handler of the originally interrupted transaction.
> > (Hmm. Maybe GDB would also have to set cr0 or something?)
>
> OK, but do we want the inferior function to be run non-transactionally?
> Should it changes be seen after the transaction aborts?
Yes, see above.
> > Is it possible for GDB to change the state (transactional vs.
> > suspended) where the kernel ought to let the application continue in?
> > I guess via modifying the appropriate MSR bits via ptrace?
>
> Yes, you can change the MSR to change the TM mode.
OK, that's good.
> > If so, there would be other options to handle this:
> >
> > (A') In the transactional state, GDB could set the MSR to suspended,
> > and modify the "normal" register set. The inferior function would
> > execute in the suspended state as in (A) above. Upon return, GDB
> > would restore the normal register set (including restoring the MSR
> > to transactional state). Once the kernel resumes the application,
> > the transaction would abort at this point.
>
> This seems ok, although again, the inferior function would have side
> effects even if the transaction aborts. Is that what we want? Can we
> say to users that the inferior function is actually be run after the
> transaction aborts?
>
> Also, we need to be careful with the stack.
See above.
> > (B') In the suspended state, GDB could set the MSR to transactional,
> > and modify the "checkpointed" register set. Once the kernel resumes
> > the application, the transaction immediately aborts and control
> > transfers to the inferior function, executing in nontransactional
> > state as in (B). Upon return, GDB would again need to restore the
> > original checkpointed register set into the normal register set,
> > set cr0 to indicate transactional abort, and continue.
>
> OK.
>
> > Using the combination of (A)+(A') would be easiest to implement
> > in GDB without modifying a lot of common code, and would have the
> > advantage that the inferior function always executes in the same
> > state (suspended), while leaving information about the interrupted
> > transaction visible.
> >
> > Using the combination of (B)+(B') would be a bit more difficult
> > to implement (but certainly feasible), and would have the advantage
> > that the inferior function always executes in nontransactional state
> > (which is what it would most likely expect, anyway). However, the
> > disadvantage is that after the inferior call returns, GDB is unable
> > to fully restore the visible inferior state as it was before (since
> > we're now in nontransactional state, and there is probably no way
> > to force us back into transactional/suspended state ...).
>
> Yep.
So right now I'd tend to prefer (A)+(A'), but the important thing is
that the kernel seems to provide all features required for GDB to
implement any of the above, so we can still make that decision later.
> Getting back to the kernel interface, are you happy with what Anshuman
> has proposed in the current series?
Given the discussion above, this seems fine to me now.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-03-18 12:53 ` Ulrich Weigand
@ 2015-03-18 22:45 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-03-18 22:45 UTC (permalink / raw)
To: Ulrich Weigand
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
> Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
>
> > Sorry for the slow response.
>
> Same here :-(
I'm going to break the cycle and respond in a few hours :-)
> > I think what you're proposing with running the inferior function in
> > suspend mode may end up corrupting the stack in this way. You'd need to
> > be really careful to make sure the inferior function is run on the stack
> > pointer of the checkpointed registers.
>
> On the other hand, if code called a subroutine after the tbegin, if we
> were using the checkpointed r1, this might corrupt the stack of the
> transactional code. (This code will never actually *run* again since
> the transaction is doomed, but we can still *inspect* it in GDB after
> the inferior call has returned, so the stack should remain unchanged.
> Well .. if the transaction is suspended, the code might in fact still
> run, so it should remain unchanged either way.)
>
> I guess we could use the minimum of transactional and checkpointed r1
> in that case, to be safe either way.
Sounds good.
<snip>
> > > Using the combination of (A)+(A') would be easiest to implement
> > > in GDB without modifying a lot of common code, and would have the
> > > advantage that the inferior function always executes in the same
> > > state (suspended), while leaving information about the interrupted
> > > transaction visible.
> > >
> > > Using the combination of (B)+(B') would be a bit more difficult
> > > to implement (but certainly feasible), and would have the advantage
> > > that the inferior function always executes in nontransactional state
> > > (which is what it would most likely expect, anyway). However, the
> > > disadvantage is that after the inferior call returns, GDB is unable
> > > to fully restore the visible inferior state as it was before (since
> > > we're now in nontransactional state, and there is probably no way
> > > to force us back into transactional/suspended state ...).
> >
> > Yep.
>
> So right now I'd tend to prefer (A)+(A'), but the important thing is
> that the kernel seems to provide all features required for GDB to
> implement any of the above, so we can still make that decision later.
>
> > Getting back to the kernel interface, are you happy with what Anshuman
> > has proposed in the current series?
>
> Given the discussion above, this seems fine to me now.
Great, we'll push through with this in mind.
Thanks!
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-03-18 22:45 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-03-18 22:45 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
> Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
>=20
> > Sorry for the slow response.
>=20
> Same here :-(
I'm going to break the cycle and respond in a few hours :-)
> > I think what you're proposing with running the inferior function in
> > suspend mode may end up corrupting the stack in this way. You'd need t=
o
> > be really careful to make sure the inferior function is run on the stac=
k
> > pointer of the checkpointed registers.
>=20
> On the other hand, if code called a subroutine after the tbegin, if we
> were using the checkpointed r1, this might corrupt the stack of the
> transactional code. (This code will never actually *run* again since
> the transaction is doomed, but we can still *inspect* it in GDB after
> the inferior call has returned, so the stack should remain unchanged.
> Well .. if the transaction is suspended, the code might in fact still
> run, so it should remain unchanged either way.)
>=20
> I guess we could use the minimum of transactional and checkpointed r1
> in that case, to be safe either way.
Sounds good.
<snip>
> > > Using the combination of (A)+(A') would be easiest to implement
> > > in GDB without modifying a lot of common code, and would have the
> > > advantage that the inferior function always executes in the same
> > > state (suspended), while leaving information about the interrupted
> > > transaction visible.
> > >
> > > Using the combination of (B)+(B') would be a bit more difficult
> > > to implement (but certainly feasible), and would have the advantage
> > > that the inferior function always executes in nontransactional state
> > > (which is what it would most likely expect, anyway). However, the
> > > disadvantage is that after the inferior call returns, GDB is unable
> > > to fully restore the visible inferior state as it was before (since
> > > we're now in nontransactional state, and there is probably no way
> > > to force us back into transactional/suspended state ...).
> >
> > Yep.
>=20
> So right now I'd tend to prefer (A)+(A'), but the important thing is
> that the kernel seems to provide all features required for GDB to
> implement any of the above, so we can still make that decision later.
>=20
> > Getting back to the kernel interface, are you happy with what Anshuman
> > has proposed in the current series?
>=20
> Given the discussion above, this seems fine to me now.
Great, we'll push through with this in mind.
Thanks!
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-03-18 22:45 ` Michael Neuling
@ 2015-03-18 22:50 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-03-18 22:50 UTC (permalink / raw)
To: Ulrich Weigand, Anshuman Khandual
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, Anshuman Khandual, kirjanov, linux-kernel,
linuxppc-dev, Michael Ellerman, oleg, palves, Paul.Clothier,
peterz, sam.bobroff, shuahkh, sukadev, tglx
On Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:
> On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
> > Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
> >
> > > Sorry for the slow response.
> >
> > Same here :-(
>
> I'm going to break the cycle and respond in a few hours :-)
>
>
> > > I think what you're proposing with running the inferior function in
> > > suspend mode may end up corrupting the stack in this way. You'd need to
> > > be really careful to make sure the inferior function is run on the stack
> > > pointer of the checkpointed registers.
> >
> > On the other hand, if code called a subroutine after the tbegin, if we
> > were using the checkpointed r1, this might corrupt the stack of the
> > transactional code. (This code will never actually *run* again since
> > the transaction is doomed, but we can still *inspect* it in GDB after
> > the inferior call has returned, so the stack should remain unchanged.
> > Well .. if the transaction is suspended, the code might in fact still
> > run, so it should remain unchanged either way.)
> >
> > I guess we could use the minimum of transactional and checkpointed r1
> > in that case, to be safe either way.
>
> Sounds good.
>
> <snip>
>
> > > > Using the combination of (A)+(A') would be easiest to implement
> > > > in GDB without modifying a lot of common code, and would have the
> > > > advantage that the inferior function always executes in the same
> > > > state (suspended), while leaving information about the interrupted
> > > > transaction visible.
> > > >
> > > > Using the combination of (B)+(B') would be a bit more difficult
> > > > to implement (but certainly feasible), and would have the advantage
> > > > that the inferior function always executes in nontransactional state
> > > > (which is what it would most likely expect, anyway). However, the
> > > > disadvantage is that after the inferior call returns, GDB is unable
> > > > to fully restore the visible inferior state as it was before (since
> > > > we're now in nontransactional state, and there is probably no way
> > > > to force us back into transactional/suspended state ...).
> > >
> > > Yep.
> >
> > So right now I'd tend to prefer (A)+(A'), but the important thing is
> > that the kernel seems to provide all features required for GDB to
> > implement any of the above, so we can still make that decision later.
> >
> > > Getting back to the kernel interface, are you happy with what Anshuman
> > > has proposed in the current series?
> >
> > Given the discussion above, this seems fine to me now.
>
> Great, we'll push through with this in mind.
Anshuman,
With that in mind, do we have a way to set the top 32bits of the MSR
(which contain the TM bits) when ptracing 32 bit processes? I can't
find anything like that in this patch set.
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-03-18 22:50 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-03-18 22:50 UTC (permalink / raw)
To: Ulrich Weigand, Anshuman Khandual
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff, Anshuman Khandual
On Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:
> On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
> > Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
> >=20
> > > Sorry for the slow response.
> >=20
> > Same here :-(
>=20
> I'm going to break the cycle and respond in a few hours :-)
>=20
>=20
> > > I think what you're proposing with running the inferior function in
> > > suspend mode may end up corrupting the stack in this way. You'd need=
to
> > > be really careful to make sure the inferior function is run on the st=
ack
> > > pointer of the checkpointed registers.
> >=20
> > On the other hand, if code called a subroutine after the tbegin, if we
> > were using the checkpointed r1, this might corrupt the stack of the
> > transactional code. (This code will never actually *run* again since
> > the transaction is doomed, but we can still *inspect* it in GDB after
> > the inferior call has returned, so the stack should remain unchanged.
> > Well .. if the transaction is suspended, the code might in fact still
> > run, so it should remain unchanged either way.)
> >=20
> > I guess we could use the minimum of transactional and checkpointed r1
> > in that case, to be safe either way.
>=20
> Sounds good.
>=20
> <snip>
>=20
> > > > Using the combination of (A)+(A') would be easiest to implement
> > > > in GDB without modifying a lot of common code, and would have the
> > > > advantage that the inferior function always executes in the same
> > > > state (suspended), while leaving information about the interrupted
> > > > transaction visible.
> > > >
> > > > Using the combination of (B)+(B') would be a bit more difficult
> > > > to implement (but certainly feasible), and would have the advantage
> > > > that the inferior function always executes in nontransactional stat=
e
> > > > (which is what it would most likely expect, anyway). However, the
> > > > disadvantage is that after the inferior call returns, GDB is unable
> > > > to fully restore the visible inferior state as it was before (since
> > > > we're now in nontransactional state, and there is probably no way
> > > > to force us back into transactional/suspended state ...).
> > >
> > > Yep.
> >=20
> > So right now I'd tend to prefer (A)+(A'), but the important thing is
> > that the kernel seems to provide all features required for GDB to
> > implement any of the above, so we can still make that decision later.
> >=20
> > > Getting back to the kernel interface, are you happy with what Anshuma=
n
> > > has proposed in the current series?
> >=20
> > Given the discussion above, this seems fine to me now.
>=20
> Great, we'll push through with this in mind.
Anshuman,
With that in mind, do we have a way to set the top 32bits of the MSR
(which contain the TM bits) when ptracing 32 bit processes? I can't
find anything like that in this patch set. =20
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-03-18 22:50 ` Michael Neuling
@ 2015-03-23 10:34 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-03-23 10:34 UTC (permalink / raw)
To: Michael Neuling, Ulrich Weigand
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz,
linux-kernel, davem, dhowells, linuxppc-dev, kirjanov, tglx,
oleg, sukadev, davej, akpm, palves, Edjunior Barbosa Machado,
sam.bobroff
On 03/19/2015 04:20 AM, Michael Neuling wrote:
> On Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:
>> On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
>>> Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
>>>
>>>> Sorry for the slow response.
>>>
>>> Same here :-(
>>
>> I'm going to break the cycle and respond in a few hours :-)
>>
>>
>>>> I think what you're proposing with running the inferior function in
>>>> suspend mode may end up corrupting the stack in this way. You'd need to
>>>> be really careful to make sure the inferior function is run on the stack
>>>> pointer of the checkpointed registers.
>>>
>>> On the other hand, if code called a subroutine after the tbegin, if we
>>> were using the checkpointed r1, this might corrupt the stack of the
>>> transactional code. (This code will never actually *run* again since
>>> the transaction is doomed, but we can still *inspect* it in GDB after
>>> the inferior call has returned, so the stack should remain unchanged.
>>> Well .. if the transaction is suspended, the code might in fact still
>>> run, so it should remain unchanged either way.)
>>>
>>> I guess we could use the minimum of transactional and checkpointed r1
>>> in that case, to be safe either way.
>>
>> Sounds good.
>>
>> <snip>
>>
>>>>> Using the combination of (A)+(A') would be easiest to implement
>>>>> in GDB without modifying a lot of common code, and would have the
>>>>> advantage that the inferior function always executes in the same
>>>>> state (suspended), while leaving information about the interrupted
>>>>> transaction visible.
>>>>>
>>>>> Using the combination of (B)+(B') would be a bit more difficult
>>>>> to implement (but certainly feasible), and would have the advantage
>>>>> that the inferior function always executes in nontransactional state
>>>>> (which is what it would most likely expect, anyway). However, the
>>>>> disadvantage is that after the inferior call returns, GDB is unable
>>>>> to fully restore the visible inferior state as it was before (since
>>>>> we're now in nontransactional state, and there is probably no way
>>>>> to force us back into transactional/suspended state ...).
>>>>
>>>> Yep.
>>>
>>> So right now I'd tend to prefer (A)+(A'), but the important thing is
>>> that the kernel seems to provide all features required for GDB to
>>> implement any of the above, so we can still make that decision later.
>>>
>>>> Getting back to the kernel interface, are you happy with what Anshuman
>>>> has proposed in the current series?
>>>
>>> Given the discussion above, this seems fine to me now.
>>
>> Great, we'll push through with this in mind.
>
> Anshuman,
>
> With that in mind, do we have a way to set the top 32bits of the MSR
> (which contain the TM bits) when ptracing 32 bit processes? I can't
> find anything like that in this patch set.
No, we dont have that yet. When ptracing in 32-bit mode the MSR value
which can be viewed or set from the user space through PTRACE_GETREGS
PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
the upper 32 bits of MSR as part of one of the ELF core notes we are
adding in the patch series or we can create one more separate ELF core
note for that purpose. Let me know your opinion on this.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-03-23 10:34 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-03-23 10:34 UTC (permalink / raw)
To: Michael Neuling, Ulrich Weigand
Cc: james.hogan, avagin, Paul.Clothier, peterz, palves,
Edjunior Barbosa Machado, linux-kernel, akpm, shuahkh, dhowells,
linuxppc-dev, kirjanov, oleg, davej, tglx, sukadev, davem,
sam.bobroff
On 03/19/2015 04:20 AM, Michael Neuling wrote:
> On Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:
>> On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
>>> Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:
>>>
>>>> Sorry for the slow response.
>>>
>>> Same here :-(
>>
>> I'm going to break the cycle and respond in a few hours :-)
>>
>>
>>>> I think what you're proposing with running the inferior function in
>>>> suspend mode may end up corrupting the stack in this way. You'd need to
>>>> be really careful to make sure the inferior function is run on the stack
>>>> pointer of the checkpointed registers.
>>>
>>> On the other hand, if code called a subroutine after the tbegin, if we
>>> were using the checkpointed r1, this might corrupt the stack of the
>>> transactional code. (This code will never actually *run* again since
>>> the transaction is doomed, but we can still *inspect* it in GDB after
>>> the inferior call has returned, so the stack should remain unchanged.
>>> Well .. if the transaction is suspended, the code might in fact still
>>> run, so it should remain unchanged either way.)
>>>
>>> I guess we could use the minimum of transactional and checkpointed r1
>>> in that case, to be safe either way.
>>
>> Sounds good.
>>
>> <snip>
>>
>>>>> Using the combination of (A)+(A') would be easiest to implement
>>>>> in GDB without modifying a lot of common code, and would have the
>>>>> advantage that the inferior function always executes in the same
>>>>> state (suspended), while leaving information about the interrupted
>>>>> transaction visible.
>>>>>
>>>>> Using the combination of (B)+(B') would be a bit more difficult
>>>>> to implement (but certainly feasible), and would have the advantage
>>>>> that the inferior function always executes in nontransactional state
>>>>> (which is what it would most likely expect, anyway). However, the
>>>>> disadvantage is that after the inferior call returns, GDB is unable
>>>>> to fully restore the visible inferior state as it was before (since
>>>>> we're now in nontransactional state, and there is probably no way
>>>>> to force us back into transactional/suspended state ...).
>>>>
>>>> Yep.
>>>
>>> So right now I'd tend to prefer (A)+(A'), but the important thing is
>>> that the kernel seems to provide all features required for GDB to
>>> implement any of the above, so we can still make that decision later.
>>>
>>>> Getting back to the kernel interface, are you happy with what Anshuman
>>>> has proposed in the current series?
>>>
>>> Given the discussion above, this seems fine to me now.
>>
>> Great, we'll push through with this in mind.
>
> Anshuman,
>
> With that in mind, do we have a way to set the top 32bits of the MSR
> (which contain the TM bits) when ptracing 32 bit processes? I can't
> find anything like that in this patch set.
No, we dont have that yet. When ptracing in 32-bit mode the MSR value
which can be viewed or set from the user space through PTRACE_GETREGS
PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
the upper 32 bits of MSR as part of one of the ELF core notes we are
adding in the patch series or we can create one more separate ELF core
note for that purpose. Let me know your opinion on this.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-03-23 10:34 ` Anshuman Khandual
@ 2015-04-08 17:50 ` Ulrich Weigand
-1 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-08 17:50 UTC (permalink / raw)
To: Anshuman Khandual
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, kirjanov, linux-kernel, linuxppc-dev,
Michael Neuling, oleg, palves, Paul.Clothier, peterz,
sam.bobroff, shuahkh, sukadev, tglx
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
11:34:30:
> > With that in mind, do we have a way to set the top 32bits of the MSR
> > (which contain the TM bits) when ptracing 32 bit processes? I can't
> > find anything like that in this patch set.
>
> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
> which can be viewed or set from the user space through PTRACE_GETREGS
> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
> the upper 32 bits of MSR as part of one of the ELF core notes we are
> adding in the patch series or we can create one more separate ELF core
> note for that purpose. Let me know your opinion on this.
I'm not sure I understand this. I thought we had the following:
- If the process calling ptrace is itself 64-bit (which is how GDB is
built on all current Linux distributions), then PTRACE_GETREGS etc.
will *always* operate on 64-bit register sets, even if the target
process is 32-bit.
- If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
operate on 32-bit register sets. However, there is a separate
PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
the opportunity to operate on the full 64-bit register set. Both
apply independently of whether the target process is 32-bit or
64-bit.
Is this not correct?
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-08 17:50 ` Ulrich Weigand
0 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-08 17:50 UTC (permalink / raw)
To: Anshuman Khandual
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
11:34:30:
> > With that in mind, do we have a way to set the top 32bits of the MSR
> > (which contain the TM bits) when ptracing 32 bit processes? I can't
> > find anything like that in this patch set.
>
> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
> which can be viewed or set from the user space through PTRACE_GETREGS
> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
> the upper 32 bits of MSR as part of one of the ELF core notes we are
> adding in the patch series or we can create one more separate ELF core
> note for that purpose. Let me know your opinion on this.
I'm not sure I understand this. I thought we had the following:
- If the process calling ptrace is itself 64-bit (which is how GDB is
built on all current Linux distributions), then PTRACE_GETREGS etc.
will *always* operate on 64-bit register sets, even if the target
process is 32-bit.
- If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
operate on 32-bit register sets. However, there is a separate
PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
the opportunity to operate on the full 64-bit register set. Both
apply independently of whether the target process is 32-bit or
64-bit.
Is this not correct?
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-08 17:50 ` Ulrich Weigand
@ 2015-04-08 23:11 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-04-08 23:11 UTC (permalink / raw)
To: Ulrich Weigand
Cc: Anshuman Khandual, akpm, avagin, davej, davem, dhowells,
Edjunior Barbosa Machado, james.hogan, kirjanov, linux-kernel,
linuxppc-dev, oleg, palves, Paul.Clothier, peterz, sam.bobroff,
shuahkh, sukadev, tglx
On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
> 11:34:30:
>
> > > With that in mind, do we have a way to set the top 32bits of the MSR
> > > (which contain the TM bits) when ptracing 32 bit processes? I can't
> > > find anything like that in this patch set.
> >
> > No, we dont have that yet. When ptracing in 32-bit mode the MSR value
> > which can be viewed or set from the user space through PTRACE_GETREGS
> > PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
> > the upper 32 bits of MSR as part of one of the ELF core notes we are
> > adding in the patch series or we can create one more separate ELF core
> > note for that purpose. Let me know your opinion on this.
>
> I'm not sure I understand this. I thought we had the following:
>
> - If the process calling ptrace is itself 64-bit (which is how GDB is
> built on all current Linux distributions), then PTRACE_GETREGS etc.
> will *always* operate on 64-bit register sets, even if the target
> process is 32-bit.
>
> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
> operate on 32-bit register sets. However, there is a separate
> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
> the opportunity to operate on the full 64-bit register set. Both
> apply independently of whether the target process is 32-bit or
> 64-bit.
>
> Is this not correct?
I think you're correct. We should be right. I'd forgotten about the
GET/SETREGS64 interfaces.
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-08 23:11 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-04-08 23:11 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz, palves,
linux-kernel, Edjunior Barbosa Machado, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev, davem, sam.bobroff,
Anshuman Khandual
On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
> 11:34:30:
>=20
> > > With that in mind, do we have a way to set the top 32bits of the MSR
> > > (which contain the TM bits) when ptracing 32 bit processes? I can't
> > > find anything like that in this patch set.
> >
> > No, we dont have that yet. When ptracing in 32-bit mode the MSR value
> > which can be viewed or set from the user space through PTRACE_GETREGS
> > PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
> > the upper 32 bits of MSR as part of one of the ELF core notes we are
> > adding in the patch series or we can create one more separate ELF core
> > note for that purpose. Let me know your opinion on this.
>=20
> I'm not sure I understand this. I thought we had the following:
>=20
> - If the process calling ptrace is itself 64-bit (which is how GDB is
> built on all current Linux distributions), then PTRACE_GETREGS etc.
> will *always* operate on 64-bit register sets, even if the target
> process is 32-bit.
>=20
> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
> operate on 32-bit register sets. However, there is a separate
> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
> the opportunity to operate on the full 64-bit register set. Both
> apply independently of whether the target process is 32-bit or
> 64-bit.
>=20
> Is this not correct?
I think you're correct. We should be right. I'd forgotten about the
GET/SETREGS64 interfaces.
Mikey
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-08 23:11 ` Michael Neuling
@ 2015-04-09 12:50 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-09 12:50 UTC (permalink / raw)
To: Michael Neuling, Ulrich Weigand
Cc: shuahkh, james.hogan, avagin, Paul.Clothier, peterz, palves,
linux-kernel, Edjunior Barbosa Machado, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev, davem, sam.bobroff
On 04/09/2015 04:41 AM, Michael Neuling wrote:
> On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
>> 11:34:30:
>>
>>>> With that in mind, do we have a way to set the top 32bits of the MSR
>>>> (which contain the TM bits) when ptracing 32 bit processes? I can't
>>>> find anything like that in this patch set.
>>>
>>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
>>> which can be viewed or set from the user space through PTRACE_GETREGS
>>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
>>> the upper 32 bits of MSR as part of one of the ELF core notes we are
>>> adding in the patch series or we can create one more separate ELF core
>>> note for that purpose. Let me know your opinion on this.
>>
>> I'm not sure I understand this. I thought we had the following:
>>
>> - If the process calling ptrace is itself 64-bit (which is how GDB is
>> built on all current Linux distributions), then PTRACE_GETREGS etc.
>> will *always* operate on 64-bit register sets, even if the target
>> process is 32-bit.
>>
>> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
>> operate on 32-bit register sets. However, there is a separate
>> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
>> the opportunity to operate on the full 64-bit register set. Both
>> apply independently of whether the target process is 32-bit or
>> 64-bit.
>>
>> Is this not correct?
>
> I think you're correct. We should be right. I'd forgotten about the
> GET/SETREGS64 interfaces.
In that case, is the patch series complete and okay ? Is there any thing
else we need to verify other than waiting for the GDB test results which
Edjunior has been working on. But I am not aware of the status on the GDB
test development front.
Edjunior,
Do you have any updates ?
Regards
Anshuman
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-09 12:50 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-09 12:50 UTC (permalink / raw)
To: Michael Neuling, Ulrich Weigand
Cc: james.hogan, avagin, Paul.Clothier, davem, peterz, palves,
shuahkh, akpm, linux-kernel, dhowells, linuxppc-dev, kirjanov,
oleg, davej, tglx, sukadev, Edjunior Barbosa Machado,
sam.bobroff
On 04/09/2015 04:41 AM, Michael Neuling wrote:
> On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
>> 11:34:30:
>>
>>>> With that in mind, do we have a way to set the top 32bits of the MSR
>>>> (which contain the TM bits) when ptracing 32 bit processes? I can't
>>>> find anything like that in this patch set.
>>>
>>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
>>> which can be viewed or set from the user space through PTRACE_GETREGS
>>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
>>> the upper 32 bits of MSR as part of one of the ELF core notes we are
>>> adding in the patch series or we can create one more separate ELF core
>>> note for that purpose. Let me know your opinion on this.
>>
>> I'm not sure I understand this. I thought we had the following:
>>
>> - If the process calling ptrace is itself 64-bit (which is how GDB is
>> built on all current Linux distributions), then PTRACE_GETREGS etc.
>> will *always* operate on 64-bit register sets, even if the target
>> process is 32-bit.
>>
>> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
>> operate on 32-bit register sets. However, there is a separate
>> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
>> the opportunity to operate on the full 64-bit register set. Both
>> apply independently of whether the target process is 32-bit or
>> 64-bit.
>>
>> Is this not correct?
>
> I think you're correct. We should be right. I'd forgotten about the
> GET/SETREGS64 interfaces.
In that case, is the patch series complete and okay ? Is there any thing
else we need to verify other than waiting for the GDB test results which
Edjunior has been working on. But I am not aware of the status on the GDB
test development front.
Edjunior,
Do you have any updates ?
Regards
Anshuman
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-09 12:50 ` Anshuman Khandual
@ 2015-04-10 3:03 ` Michael Neuling
-1 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-04-10 3:03 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Ulrich Weigand, shuahkh, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, Edjunior Barbosa Machado, dhowells,
linuxppc-dev, kirjanov, tglx, oleg, davej, akpm, sukadev, davem,
sam.bobroff
On Thu, 2015-04-09 at 18:20 +0530, Anshuman Khandual wrote:
> On 04/09/2015 04:41 AM, Michael Neuling wrote:
> > On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
> >> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
> >> 11:34:30:
> >>
> >>>> With that in mind, do we have a way to set the top 32bits of the MSR
> >>>> (which contain the TM bits) when ptracing 32 bit processes? I can't
> >>>> find anything like that in this patch set.
> >>>
> >>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
> >>> which can be viewed or set from the user space through PTRACE_GETREGS
> >>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
> >>> the upper 32 bits of MSR as part of one of the ELF core notes we are
> >>> adding in the patch series or we can create one more separate ELF core
> >>> note for that purpose. Let me know your opinion on this.
> >>
> >> I'm not sure I understand this. I thought we had the following:
> >>
> >> - If the process calling ptrace is itself 64-bit (which is how GDB is
> >> built on all current Linux distributions), then PTRACE_GETREGS etc.
> >> will *always* operate on 64-bit register sets, even if the target
> >> process is 32-bit.
> >>
> >> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
> >> operate on 32-bit register sets. However, there is a separate
> >> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
> >> the opportunity to operate on the full 64-bit register set. Both
> >> apply independently of whether the target process is 32-bit or
> >> 64-bit.
> >>
> >> Is this not correct?
> >
> > I think you're correct. We should be right. I'd forgotten about the
> > GET/SETREGS64 interfaces.
>
> In that case, is the patch series complete and okay ? Is there any thing
> else we need to verify other than waiting for the GDB test results which
> Edjunior has been working on. But I am not aware of the status on the GDB
> test development front.
I think we are good.
Mikey
>
> Edjunior,
>
> Do you have any updates ?
>
> Regards
> Anshuman
>
>
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-10 3:03 ` Michael Neuling
0 siblings, 0 replies; 80+ messages in thread
From: Michael Neuling @ 2015-04-10 3:03 UTC (permalink / raw)
To: Anshuman Khandual
Cc: james.hogan, avagin, Paul.Clothier, linuxppc-dev, peterz, palves,
davem, shuahkh, akpm, linux-kernel, dhowells, Ulrich Weigand,
kirjanov, oleg, davej, tglx, sukadev, Edjunior Barbosa Machado,
sam.bobroff
On Thu, 2015-04-09 at 18:20 +0530, Anshuman Khandual wrote:
> On 04/09/2015 04:41 AM, Michael Neuling wrote:
> > On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
> >> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
> >> 11:34:30:
> >>
> >>>> With that in mind, do we have a way to set the top 32bits of the MSR
> >>>> (which contain the TM bits) when ptracing 32 bit processes? I can't
> >>>> find anything like that in this patch set.
> >>>
> >>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
> >>> which can be viewed or set from the user space through PTRACE_GETREGS
> >>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
> >>> the upper 32 bits of MSR as part of one of the ELF core notes we are
> >>> adding in the patch series or we can create one more separate ELF cor=
e
> >>> note for that purpose. Let me know your opinion on this.
> >>
> >> I'm not sure I understand this. I thought we had the following:
> >>
> >> - If the process calling ptrace is itself 64-bit (which is how GDB is
> >> built on all current Linux distributions), then PTRACE_GETREGS etc.
> >> will *always* operate on 64-bit register sets, even if the target
> >> process is 32-bit.
> >>
> >> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
> >> operate on 32-bit register sets. However, there is a separate
> >> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
> >> the opportunity to operate on the full 64-bit register set. Both
> >> apply independently of whether the target process is 32-bit or
> >> 64-bit.
> >>
> >> Is this not correct?
> >=20
> > I think you're correct. We should be right. I'd forgotten about the
> > GET/SETREGS64 interfaces.
>=20
> In that case, is the patch series complete and okay ? Is there any thing
> else we need to verify other than waiting for the GDB test results which
> Edjunior has been working on. But I am not aware of the status on the GDB
> test development front.
I think we are good.
Mikey
>=20
> Edjunior,
>=20
> Do you have any updates ?
>=20
> Regards
> Anshuman
>=20
>=20
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-10 3:03 ` Michael Neuling
@ 2015-04-10 9:10 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-10 9:10 UTC (permalink / raw)
To: Michael Neuling
Cc: james.hogan, avagin, Paul.Clothier, linuxppc-dev, peterz, palves,
davem, shuahkh, akpm, linux-kernel, dhowells, Ulrich Weigand,
kirjanov, oleg, davej, tglx, sukadev, Edjunior Barbosa Machado,
sam.bobroff
On 04/10/2015 08:33 AM, Michael Neuling wrote:
> On Thu, 2015-04-09 at 18:20 +0530, Anshuman Khandual wrote:
>> On 04/09/2015 04:41 AM, Michael Neuling wrote:
>>> On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
>>>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
>>>> 11:34:30:
>>>>
>>>>>> With that in mind, do we have a way to set the top 32bits of the MSR
>>>>>> (which contain the TM bits) when ptracing 32 bit processes? I can't
>>>>>> find anything like that in this patch set.
>>>>>
>>>>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
>>>>> which can be viewed or set from the user space through PTRACE_GETREGS
>>>>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
>>>>> the upper 32 bits of MSR as part of one of the ELF core notes we are
>>>>> adding in the patch series or we can create one more separate ELF core
>>>>> note for that purpose. Let me know your opinion on this.
>>>>
>>>> I'm not sure I understand this. I thought we had the following:
>>>>
>>>> - If the process calling ptrace is itself 64-bit (which is how GDB is
>>>> built on all current Linux distributions), then PTRACE_GETREGS etc.
>>>> will *always* operate on 64-bit register sets, even if the target
>>>> process is 32-bit.
>>>>
>>>> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
>>>> operate on 32-bit register sets. However, there is a separate
>>>> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
>>>> the opportunity to operate on the full 64-bit register set. Both
>>>> apply independently of whether the target process is 32-bit or
>>>> 64-bit.
>>>>
>>>> Is this not correct?
>>>
>>> I think you're correct. We should be right. I'd forgotten about the
>>> GET/SETREGS64 interfaces.
>>
>> In that case, is the patch series complete and okay ? Is there any thing
>> else we need to verify other than waiting for the GDB test results which
>> Edjunior has been working on. But I am not aware of the status on the GDB
>> test development front.
>
> I think we are good.
I had posted a newer version [V7] of this patch series couple of months back
which got ignored while the discussion continued in this version.
V7: https://lkml.org/lkml/2015/1/14/19
Apart from the last gitignore related patch which already got merged into
mainline separately, all other patches should be as good even today. I will
try rebasing the series, running the base tests again and re post it in some
time.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-10 9:10 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-10 9:10 UTC (permalink / raw)
To: Michael Neuling
Cc: james.hogan, avagin, Paul.Clothier, Ulrich Weigand, peterz,
palves, Edjunior Barbosa Machado, shuahkh, linux-kernel,
dhowells, linuxppc-dev, kirjanov, tglx, oleg, davej, akpm,
sukadev, davem, sam.bobroff
On 04/10/2015 08:33 AM, Michael Neuling wrote:
> On Thu, 2015-04-09 at 18:20 +0530, Anshuman Khandual wrote:
>> On 04/09/2015 04:41 AM, Michael Neuling wrote:
>>> On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
>>>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
>>>> 11:34:30:
>>>>
>>>>>> With that in mind, do we have a way to set the top 32bits of the MSR
>>>>>> (which contain the TM bits) when ptracing 32 bit processes? I can't
>>>>>> find anything like that in this patch set.
>>>>>
>>>>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
>>>>> which can be viewed or set from the user space through PTRACE_GETREGS
>>>>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
>>>>> the upper 32 bits of MSR as part of one of the ELF core notes we are
>>>>> adding in the patch series or we can create one more separate ELF core
>>>>> note for that purpose. Let me know your opinion on this.
>>>>
>>>> I'm not sure I understand this. I thought we had the following:
>>>>
>>>> - If the process calling ptrace is itself 64-bit (which is how GDB is
>>>> built on all current Linux distributions), then PTRACE_GETREGS etc.
>>>> will *always* operate on 64-bit register sets, even if the target
>>>> process is 32-bit.
>>>>
>>>> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
>>>> operate on 32-bit register sets. However, there is a separate
>>>> PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
>>>> the opportunity to operate on the full 64-bit register set. Both
>>>> apply independently of whether the target process is 32-bit or
>>>> 64-bit.
>>>>
>>>> Is this not correct?
>>>
>>> I think you're correct. We should be right. I'd forgotten about the
>>> GET/SETREGS64 interfaces.
>>
>> In that case, is the patch series complete and okay ? Is there any thing
>> else we need to verify other than waiting for the GDB test results which
>> Edjunior has been working on. But I am not aware of the status on the GDB
>> test development front.
>
> I think we are good.
I had posted a newer version [V7] of this patch series couple of months back
which got ignored while the discussion continued in this version.
V7: https://lkml.org/lkml/2015/1/14/19
Apart from the last gitignore related patch which already got merged into
mainline separately, all other patches should be as good even today. I will
try rebasing the series, running the base tests again and re post it in some
time.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-10 9:10 ` Anshuman Khandual
@ 2015-04-10 10:33 ` Ulrich Weigand
-1 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-10 10:33 UTC (permalink / raw)
To: Anshuman Khandual
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, kirjanov, linux-kernel, linuxppc-dev,
Michael Neuling, oleg, palves, Paul.Clothier, peterz,
sam.bobroff, shuahkh, sukadev, tglx
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 10.04.2015
11:10:35:
> I had posted a newer version [V7] of this patch series couple of months
back
> which got ignored while the discussion continued in this version.
>
> V7: https://lkml.org/lkml/2015/1/14/19
Ah, with all the back-and-forth on the checkpointed state, I never looked
at this. Unfortunately, there's still a number of issues with this, I
think:
- You provide checkpointed FPR and VMX registers, but there doesn't seem
to be any way to get at the checkpointed *VSX* registers (i.e. the part
that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
- We may have had this discussion in the past, but I still do not like the
notion of a "misc" register set, in particular since the three registers
in it are available at different architecture levels and categories.
I would much prefer three separate regsets (e.g. NT_PPC_DSCR, NT_PPC_PPR,
and NT_PPC_TAR), each of which is available and valid if and only if the
current processor actually has the register in question.
If we do have a single regset, at the very least a "get" operation should
set registers unvailable on the machine to a defined state (zero?)
instead of simply leaving memory uninitialized.
- Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
matches
registers with different "lifetimes". The transactional memory registers
(TFHAR, TEXASR, TFIAR) are available *always* on machines that support
transactions. But the other registers in that regset are checkpointed
versions that are only available/valid within a transaction. I think a
better way to faithfully represent this would be to have the
NT_PPC_TM_SPR
regset only contain the transcational memory registers, and use separate
regsets for the checkpointed registers -- those should parallel the non-
checkpointed register regset.
For example, if we have NT_PPC_DSCR, there should be a NT_PPC_CDSCR for
the checkpointed version etc. (If we do stay with MISC, there should
then
be a CMISC).
- Particularly confusing to me is the "checkpointed original MSR" which
currently also resides in NT_PPC_TM_SPR. What exactly is this? How
does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
I may be misreading kernel code, but it seems the kernel does not
actually
use the ckpt_regs.msr slot at all, and therefore the corresponding slot
of
the NT_PPC_TM_CGPR regset is likewise undefined/unused. Would it not be
more consistent to use that slot to pass the checkpointed MSR?
In any case, it seems the ptrace set-register case currently allows user
space to restore *any* arbitrary value into the checkpointed MSR, which
would presumably get restored into the real MSR at some point, unless I'm
missing something here. Do we not need a check that only safe bits are
modified, just like with ptrace access to the real MSR?
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-10 10:33 ` Ulrich Weigand
0 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-10 10:33 UTC (permalink / raw)
To: Anshuman Khandual
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 10.04.2015
11:10:35:
> I had posted a newer version [V7] of this patch series couple of months
back
> which got ignored while the discussion continued in this version.
>
> V7: https://lkml.org/lkml/2015/1/14/19
Ah, with all the back-and-forth on the checkpointed state, I never looked
at this. Unfortunately, there's still a number of issues with this, I
think:
- You provide checkpointed FPR and VMX registers, but there doesn't seem
to be any way to get at the checkpointed *VSX* registers (i.e. the part
that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
- We may have had this discussion in the past, but I still do not like the
notion of a "misc" register set, in particular since the three registers
in it are available at different architecture levels and categories.
I would much prefer three separate regsets (e.g. NT_PPC_DSCR, NT_PPC_PPR,
and NT_PPC_TAR), each of which is available and valid if and only if the
current processor actually has the register in question.
If we do have a single regset, at the very least a "get" operation should
set registers unvailable on the machine to a defined state (zero?)
instead of simply leaving memory uninitialized.
- Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
matches
registers with different "lifetimes". The transactional memory registers
(TFHAR, TEXASR, TFIAR) are available *always* on machines that support
transactions. But the other registers in that regset are checkpointed
versions that are only available/valid within a transaction. I think a
better way to faithfully represent this would be to have the
NT_PPC_TM_SPR
regset only contain the transcational memory registers, and use separate
regsets for the checkpointed registers -- those should parallel the non-
checkpointed register regset.
For example, if we have NT_PPC_DSCR, there should be a NT_PPC_CDSCR for
the checkpointed version etc. (If we do stay with MISC, there should
then
be a CMISC).
- Particularly confusing to me is the "checkpointed original MSR" which
currently also resides in NT_PPC_TM_SPR. What exactly is this? How
does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
I may be misreading kernel code, but it seems the kernel does not
actually
use the ckpt_regs.msr slot at all, and therefore the corresponding slot
of
the NT_PPC_TM_CGPR regset is likewise undefined/unused. Would it not be
more consistent to use that slot to pass the checkpointed MSR?
In any case, it seems the ptrace set-register case currently allows user
space to restore *any* arbitrary value into the checkpointed MSR, which
would presumably get restored into the real MSR at some point, unless I'm
missing something here. Do we not need a check that only safe bits are
modified, just like with ptrace access to the real MSR?
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-10 10:33 ` Ulrich Weigand
@ 2015-04-13 8:48 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-13 8:48 UTC (permalink / raw)
To: Ulrich Weigand
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, kirjanov, linux-kernel, linuxppc-dev,
Michael Neuling, oleg, palves, Paul.Clothier, peterz,
sam.bobroff, shuahkh, sukadev, tglx
On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 10.04.2015
> 11:10:35:
>
>> I had posted a newer version [V7] of this patch series couple of months
> back
>> which got ignored while the discussion continued in this version.
>>
>> V7: https://lkml.org/lkml/2015/1/14/19
>
> Ah, with all the back-and-forth on the checkpointed state, I never looked
> at this. Unfortunately, there's still a number of issues with this, I
> think:
>
> - You provide checkpointed FPR and VMX registers, but there doesn't seem
> to be any way to get at the checkpointed *VSX* registers (i.e. the part
> that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
Will change vsr_get, vsr_set functions as we have done for fpr_get and fpr_set
functions. Also will add one more ELF core note NT_PPC_TM_CVSX to fetch the
check pointed state of VSX register while inside the transaction.
>
> - We may have had this discussion in the past, but I still do not like the
> notion of a "misc" register set, in particular since the three registers
> in it are available at different architecture levels and categories.
Misc category as always stands for registers which can not be easily classified
into any meaningful categories.
>
> I would much prefer three separate regsets (e.g. NT_PPC_DSCR, NT_PPC_PPR,
> and NT_PPC_TAR), each of which is available and valid if and only if the
> current processor actually has the register in question.
Thats like adding one ELF core note for every single register because we cannot
put them in any category. Then as Michael Ellerman had pointed out to include
a lot more registers in this MISC category (which we are not doing right now
in the interest of having minimum support available before we look at the full
possible list of MISC registers), we should add one ELF core note section for
each of those individual registers ? I am not sure.
>
> If we do have a single regset, at the very least a "get" operation should
> set registers unvailable on the machine to a defined state (zero?)
> instead of simply leaving memory uninitialized.
Yeah sure, we can do that.
>
> - Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
> matches
> registers with different "lifetimes". The transactional memory registers
> (TFHAR, TEXASR, TFIAR) are available *always* on machines that support
> transactions. But the other registers in that regset are checkpointed
> versions that are only available/valid within a transaction. I think a
> better way to faithfully represent this would be to have the
> NT_PPC_TM_SPR
> regset only contain the transcational memory registers, and use separate
> regsets for the checkpointed registers -- those should parallel the non-
> checkpointed register regset.
Right now, we support NT_PPC_TM_SPR only inside the transaction, so we dont
have the problem with different "lifetimes" registers accessed together. But
yes, I get your point.
>
> For example, if we have NT_PPC_DSCR, there should be a NT_PPC_CDSCR for
> the checkpointed version etc. (If we do stay with MISC, there should
> then
> be a CMISC).
But then NT_PPC_MISC and NT_PPC_CMISC can contain different set of registers.
NT_PPC_CMISC will contain the orig_msr for now which the other elf core note
does not have and NT_PPC_MISC will grow to have lot more registers in the
future leaving behind NT_PPC_CMISC as it is. Need to take care of these.
>
> - Particularly confusing to me is the "checkpointed original MSR" which
> currently also resides in NT_PPC_TM_SPR. What exactly is this? How
> does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
I believed it stores the check pointed MSR value which was in the register
before the transaction started. But then how it is different from the
ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
more on this. I can see "orig_msr" getting used in many places to hold the
check pointed value of MSR.
>
> I may be misreading kernel code, but it seems the kernel does not
> actually
> use the ckpt_regs.msr slot at all, and therefore the corresponding slot
> of
> the NT_PPC_TM_CGPR regset is likewise undefined/unused. Would it not be
> more consistent to use that slot to pass the checkpointed MSR?
Hmm. Its a valid point. Would like to get some more clarity on this from
Mikey whether that slot can be used for check pointed MSR value or not.
Then why did we have these two slots to hold the same check pointed MSR
value in the first place at all. Getting confused a bit.
>
> In any case, it seems the ptrace set-register case currently allows user
> space to restore *any* arbitrary value into the checkpointed MSR, which
> would presumably get restored into the real MSR at some point, unless I'm
> missing something here. Do we not need a check that only safe bits are
> modified, just like with ptrace access to the real MSR?
Where and which safe bits do we check before writing any value into the MSR
register from ptrace interface ? May be I am missing something here.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-13 8:48 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-13 8:48 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 10.04.2015
> 11:10:35:
>
>> I had posted a newer version [V7] of this patch series couple of months
> back
>> which got ignored while the discussion continued in this version.
>>
>> V7: https://lkml.org/lkml/2015/1/14/19
>
> Ah, with all the back-and-forth on the checkpointed state, I never looked
> at this. Unfortunately, there's still a number of issues with this, I
> think:
>
> - You provide checkpointed FPR and VMX registers, but there doesn't seem
> to be any way to get at the checkpointed *VSX* registers (i.e. the part
> that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
Will change vsr_get, vsr_set functions as we have done for fpr_get and fpr_set
functions. Also will add one more ELF core note NT_PPC_TM_CVSX to fetch the
check pointed state of VSX register while inside the transaction.
>
> - We may have had this discussion in the past, but I still do not like the
> notion of a "misc" register set, in particular since the three registers
> in it are available at different architecture levels and categories.
Misc category as always stands for registers which can not be easily classified
into any meaningful categories.
>
> I would much prefer three separate regsets (e.g. NT_PPC_DSCR, NT_PPC_PPR,
> and NT_PPC_TAR), each of which is available and valid if and only if the
> current processor actually has the register in question.
Thats like adding one ELF core note for every single register because we cannot
put them in any category. Then as Michael Ellerman had pointed out to include
a lot more registers in this MISC category (which we are not doing right now
in the interest of having minimum support available before we look at the full
possible list of MISC registers), we should add one ELF core note section for
each of those individual registers ? I am not sure.
>
> If we do have a single regset, at the very least a "get" operation should
> set registers unvailable on the machine to a defined state (zero?)
> instead of simply leaving memory uninitialized.
Yeah sure, we can do that.
>
> - Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
> matches
> registers with different "lifetimes". The transactional memory registers
> (TFHAR, TEXASR, TFIAR) are available *always* on machines that support
> transactions. But the other registers in that regset are checkpointed
> versions that are only available/valid within a transaction. I think a
> better way to faithfully represent this would be to have the
> NT_PPC_TM_SPR
> regset only contain the transcational memory registers, and use separate
> regsets for the checkpointed registers -- those should parallel the non-
> checkpointed register regset.
Right now, we support NT_PPC_TM_SPR only inside the transaction, so we dont
have the problem with different "lifetimes" registers accessed together. But
yes, I get your point.
>
> For example, if we have NT_PPC_DSCR, there should be a NT_PPC_CDSCR for
> the checkpointed version etc. (If we do stay with MISC, there should
> then
> be a CMISC).
But then NT_PPC_MISC and NT_PPC_CMISC can contain different set of registers.
NT_PPC_CMISC will contain the orig_msr for now which the other elf core note
does not have and NT_PPC_MISC will grow to have lot more registers in the
future leaving behind NT_PPC_CMISC as it is. Need to take care of these.
>
> - Particularly confusing to me is the "checkpointed original MSR" which
> currently also resides in NT_PPC_TM_SPR. What exactly is this? How
> does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
I believed it stores the check pointed MSR value which was in the register
before the transaction started. But then how it is different from the
ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
more on this. I can see "orig_msr" getting used in many places to hold the
check pointed value of MSR.
>
> I may be misreading kernel code, but it seems the kernel does not
> actually
> use the ckpt_regs.msr slot at all, and therefore the corresponding slot
> of
> the NT_PPC_TM_CGPR regset is likewise undefined/unused. Would it not be
> more consistent to use that slot to pass the checkpointed MSR?
Hmm. Its a valid point. Would like to get some more clarity on this from
Mikey whether that slot can be used for check pointed MSR value or not.
Then why did we have these two slots to hold the same check pointed MSR
value in the first place at all. Getting confused a bit.
>
> In any case, it seems the ptrace set-register case currently allows user
> space to restore *any* arbitrary value into the checkpointed MSR, which
> would presumably get restored into the real MSR at some point, unless I'm
> missing something here. Do we not need a check that only safe bits are
> modified, just like with ptrace access to the real MSR?
Where and which safe bits do we check before writing any value into the MSR
register from ptrace interface ? May be I am missing something here.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-13 8:48 ` Anshuman Khandual
@ 2015-04-20 6:42 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-20 6:42 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
On 04/13/2015 02:18 PM, Anshuman Khandual wrote:
> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 10.04.2015
>> 11:10:35:
>
> I believed it stores the check pointed MSR value which was in the register
> before the transaction started. But then how it is different from the
> ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
> more on this. I can see "orig_msr" getting used in many places to hold the
> check pointed value of MSR.
tm_orig_msr is used during process context switch only. ckpt_regs
gets used in the signal context where we save all userspace context.
So ptrace would look into the saved MSR value correctly inside
ckpt_regs.msr slot. I believe thats the check pointed MSR value
we are interested in from the ptrace perspective not the tm_orig_msr
which just gets used during process context switch.
>> I may be misreading kernel code, but it seems the kernel does not
>> actually
>> use the ckpt_regs.msr slot at all, and therefore the corresponding slot
>> of
>> the NT_PPC_TM_CGPR regset is likewise undefined/unused. Would it not be
>> more consistent to use that slot to pass the checkpointed MSR?
>
> Hmm. Its a valid point. Would like to get some more clarity on this from
> Mikey whether that slot can be used for check pointed MSR value or not.
> Then why did we have these two slots to hold the same check pointed MSR
> value in the first place at all. Getting confused a bit.
Using ckpt_regs.msr during process context switch instead of tm_orig_msr seems
to be working fine and all the basic TM tests pass, in which case we can drop
tm_orig_msr from thread_struct. Will post a patch on this and see whats the
response from others.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-20 6:42 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-20 6:42 UTC (permalink / raw)
To: Ulrich Weigand
Cc: Michael Neuling, james.hogan, avagin, Paul.Clothier, peterz,
palves, Edjunior Barbosa Machado, shuahkh, akpm, linux-kernel,
dhowells, linuxppc-dev, kirjanov, oleg, davej, tglx, sukadev,
davem, sam.bobroff
On 04/13/2015 02:18 PM, Anshuman Khandual wrote:
> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 10.04.2015
>> 11:10:35:
>
> I believed it stores the check pointed MSR value which was in the register
> before the transaction started. But then how it is different from the
> ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
> more on this. I can see "orig_msr" getting used in many places to hold the
> check pointed value of MSR.
tm_orig_msr is used during process context switch only. ckpt_regs
gets used in the signal context where we save all userspace context.
So ptrace would look into the saved MSR value correctly inside
ckpt_regs.msr slot. I believe thats the check pointed MSR value
we are interested in from the ptrace perspective not the tm_orig_msr
which just gets used during process context switch.
>> I may be misreading kernel code, but it seems the kernel does not
>> actually
>> use the ckpt_regs.msr slot at all, and therefore the corresponding slot
>> of
>> the NT_PPC_TM_CGPR regset is likewise undefined/unused. Would it not be
>> more consistent to use that slot to pass the checkpointed MSR?
>
> Hmm. Its a valid point. Would like to get some more clarity on this from
> Mikey whether that slot can be used for check pointed MSR value or not.
> Then why did we have these two slots to hold the same check pointed MSR
> value in the first place at all. Getting confused a bit.
Using ckpt_regs.msr during process context switch instead of tm_orig_msr seems
to be working fine and all the basic TM tests pass, in which case we can drop
tm_orig_msr from thread_struct. Will post a patch on this and see whats the
response from others.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-13 8:48 ` Anshuman Khandual
@ 2015-04-20 12:27 ` Ulrich Weigand
-1 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-20 12:27 UTC (permalink / raw)
To: Anshuman Khandual
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, kirjanov, linux-kernel, linuxppc-dev,
Michael Neuling, oleg, palves, Paul.Clothier, peterz,
sam.bobroff, shuahkh, sukadev, tglx
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 13.04.2015
10:48:57:
> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
> > - You provide checkpointed FPR and VMX registers, but there doesn't
seem
> > to be any way to get at the checkpointed *VSX* registers (i.e. the
part
> > that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
>
> Will change vsr_get, vsr_set functions as we have done for fpr_get and
fpr_set
> functions. Also will add one more ELF core note NT_PPC_TM_CVSX to fetch
the
> check pointed state of VSX register while inside the transaction.
OK.
> > I would much prefer three separate regsets (e.g. NT_PPC_DSCR,
NT_PPC_PPR,
> > and NT_PPC_TAR), each of which is available and valid if and only if
the
> > current processor actually has the register in question.
>
> Thats like adding one ELF core note for every single register
> because we cannot
> put them in any category. Then as Michael Ellerman had pointed out to
include
> a lot more registers in this MISC category (which we are not doing right
now
> in the interest of having minimum support available before we look at the
full
> possible list of MISC registers), we should add one ELF core note section
for
> each of those individual registers ? I am not sure.
This confuses me a bit. My understanding was that ptrace regsets, once
defined, should never change in the future. (GDB will only check whether
or not a regset is supported; if it is, it will expect the contents to be
as it expects them to be.) "Including a lot more registers" would
therefore
seem to require adding new regsets anyway, which is one of the reasons why
I disagree a "MISC" regset is particularly useful.
> > - Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
> > matches
> > registers with different "lifetimes". The transactional memory
registers
> > (TFHAR, TEXASR, TFIAR) are available *always* on machines that
support
> > transactions. But the other registers in that regset are
checkpointed
> > versions that are only available/valid within a transaction. I think
a
> > better way to faithfully represent this would be to have the
> > NT_PPC_TM_SPR
> > regset only contain the transcational memory registers, and use
separate
> > regsets for the checkpointed registers -- those should parallel the
non-
> > checkpointed register regset.
>
> Right now, we support NT_PPC_TM_SPR only inside the transaction, so we
dont
> have the problem with different "lifetimes" registers accessed together.
But
> yes, I get your point.
Since the transactional SPRs are accessible from user space outside of a
transaction, it would make sense for them to accessible from ptrace as
well.
If the current patch set doesn't do that, I guess it would be better to
change that.
> > - Particularly confusing to me is the "checkpointed original MSR" which
> > currently also resides in NT_PPC_TM_SPR. What exactly is this? How
> > does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
>
> I believed it stores the check pointed MSR value which was in the
register
> before the transaction started. But then how it is different from the
> ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
> more on this. I can see "orig_msr" getting used in many places to hold
the
> check pointed value of MSR.
Your other mail states that the orig_mst may be irrelevant for ptrace
anyway ... that would be OK with me as well.
> > In any case, it seems the ptrace set-register case currently allows
user
> > space to restore *any* arbitrary value into the checkpointed MSR,
which
> > would presumably get restored into the real MSR at some point, unless
I'm
> > missing something here. Do we not need a check that only safe bits
are
> > modified, just like with ptrace access to the real MSR?
>
> Where and which safe bits do we check before writing any value into the
MSR
> register from ptrace interface ? May be I am missing something here.
All ptrace accesses to *set* the regular msr go via this routine:
static int set_user_msr(struct task_struct *task, unsigned long msr)
{
task->thread.regs->msr &= ~MSR_DEBUGCHANGE;
task->thread.regs->msr |= msr & MSR_DEBUGCHANGE;
return 0;
}
I think we'd need to do the equivalent whenever changing the checkpointed
MSR.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-20 12:27 ` Ulrich Weigand
0 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-20 12:27 UTC (permalink / raw)
To: Anshuman Khandual
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 13.04.2015
10:48:57:
> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
> > - You provide checkpointed FPR and VMX registers, but there doesn't
seem
> > to be any way to get at the checkpointed *VSX* registers (i.e. the
part
> > that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
>
> Will change vsr_get, vsr_set functions as we have done for fpr_get and
fpr_set
> functions. Also will add one more ELF core note NT_PPC_TM_CVSX to fetch
the
> check pointed state of VSX register while inside the transaction.
OK.
> > I would much prefer three separate regsets (e.g. NT_PPC_DSCR,
NT_PPC_PPR,
> > and NT_PPC_TAR), each of which is available and valid if and only if
the
> > current processor actually has the register in question.
>
> Thats like adding one ELF core note for every single register
> because we cannot
> put them in any category. Then as Michael Ellerman had pointed out to
include
> a lot more registers in this MISC category (which we are not doing right
now
> in the interest of having minimum support available before we look at the
full
> possible list of MISC registers), we should add one ELF core note section
for
> each of those individual registers ? I am not sure.
This confuses me a bit. My understanding was that ptrace regsets, once
defined, should never change in the future. (GDB will only check whether
or not a regset is supported; if it is, it will expect the contents to be
as it expects them to be.) "Including a lot more registers" would
therefore
seem to require adding new regsets anyway, which is one of the reasons why
I disagree a "MISC" regset is particularly useful.
> > - Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
> > matches
> > registers with different "lifetimes". The transactional memory
registers
> > (TFHAR, TEXASR, TFIAR) are available *always* on machines that
support
> > transactions. But the other registers in that regset are
checkpointed
> > versions that are only available/valid within a transaction. I think
a
> > better way to faithfully represent this would be to have the
> > NT_PPC_TM_SPR
> > regset only contain the transcational memory registers, and use
separate
> > regsets for the checkpointed registers -- those should parallel the
non-
> > checkpointed register regset.
>
> Right now, we support NT_PPC_TM_SPR only inside the transaction, so we
dont
> have the problem with different "lifetimes" registers accessed together.
But
> yes, I get your point.
Since the transactional SPRs are accessible from user space outside of a
transaction, it would make sense for them to accessible from ptrace as
well.
If the current patch set doesn't do that, I guess it would be better to
change that.
> > - Particularly confusing to me is the "checkpointed original MSR" which
> > currently also resides in NT_PPC_TM_SPR. What exactly is this? How
> > does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
>
> I believed it stores the check pointed MSR value which was in the
register
> before the transaction started. But then how it is different from the
> ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
> more on this. I can see "orig_msr" getting used in many places to hold
the
> check pointed value of MSR.
Your other mail states that the orig_mst may be irrelevant for ptrace
anyway ... that would be OK with me as well.
> > In any case, it seems the ptrace set-register case currently allows
user
> > space to restore *any* arbitrary value into the checkpointed MSR,
which
> > would presumably get restored into the real MSR at some point, unless
I'm
> > missing something here. Do we not need a check that only safe bits
are
> > modified, just like with ptrace access to the real MSR?
>
> Where and which safe bits do we check before writing any value into the
MSR
> register from ptrace interface ? May be I am missing something here.
All ptrace accesses to *set* the regular msr go via this routine:
static int set_user_msr(struct task_struct *task, unsigned long msr)
{
task->thread.regs->msr &= ~MSR_DEBUGCHANGE;
task->thread.regs->msr |= msr & MSR_DEBUGCHANGE;
return 0;
}
I think we'd need to do the equivalent whenever changing the checkpointed
MSR.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-20 12:27 ` Ulrich Weigand
@ 2015-04-21 4:55 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-21 4:55 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
On 04/20/2015 05:57 PM, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 13.04.2015
> 10:48:57:
>> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
>>> - You provide checkpointed FPR and VMX registers, but there doesn't
> seem
>>> to be any way to get at the checkpointed *VSX* registers (i.e. the
> part
>>> that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
>>
>> Will change vsr_get, vsr_set functions as we have done for fpr_get and
> fpr_set
>> functions. Also will add one more ELF core note NT_PPC_TM_CVSX to fetch
> the
>> check pointed state of VSX register while inside the transaction.
>
> OK.
>
>>> I would much prefer three separate regsets (e.g. NT_PPC_DSCR,
> NT_PPC_PPR,
>>> and NT_PPC_TAR), each of which is available and valid if and only if
> the
>>> current processor actually has the register in question.
>>
>> Thats like adding one ELF core note for every single register
>> because we cannot
>> put them in any category. Then as Michael Ellerman had pointed out to
> include
>> a lot more registers in this MISC category (which we are not doing right
> now
>> in the interest of having minimum support available before we look at the
> full
>> possible list of MISC registers), we should add one ELF core note section
> for
>> each of those individual registers ? I am not sure.
>
> This confuses me a bit. My understanding was that ptrace regsets, once
> defined, should never change in the future. (GDB will only check whether
> or not a regset is supported; if it is, it will expect the contents to be
> as it expects them to be.) "Including a lot more registers" would
> therefore
> seem to require adding new regsets anyway, which is one of the reasons why
> I disagree a "MISC" regset is particularly useful.
Yeah right. Started thinking that (NT_PPC_TAR, NT_PPC_CTAR),
(NT_PPC_PPR, NT_PPC_CPPR), (NT_PPC_DSCR, NT_PPC_CDSCR) kind of combinations
make more sense !
>
>>> - Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
>>> matches
>>> registers with different "lifetimes". The transactional memory
> registers
>>> (TFHAR, TEXASR, TFIAR) are available *always* on machines that
> support
>>> transactions. But the other registers in that regset are
> checkpointed
>>> versions that are only available/valid within a transaction. I think
> a
>>> better way to faithfully represent this would be to have the
>>> NT_PPC_TM_SPR
>>> regset only contain the transcational memory registers, and use
> separate
>>> regsets for the checkpointed registers -- those should parallel the
> non-
>>> checkpointed register regset.
>>
>> Right now, we support NT_PPC_TM_SPR only inside the transaction, so we
> dont
>> have the problem with different "lifetimes" registers accessed together.
> But
>> yes, I get your point.
>
> Since the transactional SPRs are accessible from user space outside of a
> transaction, it would make sense for them to accessible from ptrace as
> well.
> If the current patch set doesn't do that, I guess it would be better to
> change that.
Yeah I agree. Will change it.
>
>>> - Particularly confusing to me is the "checkpointed original MSR" which
>>> currently also resides in NT_PPC_TM_SPR. What exactly is this? How
>>> does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
>>
>> I believed it stores the check pointed MSR value which was in the
> register
>> before the transaction started. But then how it is different from the
>> ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
>> more on this. I can see "orig_msr" getting used in many places to hold
> the
>> check pointed value of MSR.
>
> Your other mail states that the orig_mst may be irrelevant for ptrace
> anyway ... that would be OK with me as well.
Yeah. The variable tm_orig_msr is used to compute MSR state inside
the kernel or what would be passed to the user space while returning
at various stages of the transaction, where as ckpt_regs.msr contains
the latest check pointed MSR value to be fetched by ptrace. Thats my
understanding as of now.
>
>>> In any case, it seems the ptrace set-register case currently allows
> user
>>> space to restore *any* arbitrary value into the checkpointed MSR,
> which
>>> would presumably get restored into the real MSR at some point, unless
> I'm
>>> missing something here. Do we not need a check that only safe bits
> are
>>> modified, just like with ptrace access to the real MSR?
>>
>> Where and which safe bits do we check before writing any value into the
> MSR
>> register from ptrace interface ? May be I am missing something here.
>
> All ptrace accesses to *set* the regular msr go via this routine:
>
> static int set_user_msr(struct task_struct *task, unsigned long msr)
> {
> task->thread.regs->msr &= ~MSR_DEBUGCHANGE;
> task->thread.regs->msr |= msr & MSR_DEBUGCHANGE;
> return 0;
> }
>
> I think we'd need to do the equivalent whenever changing the checkpointed
> MSR.
Agree, will incorporate this change.
In summary, after putting together all the issues that we have
discussed till now regarding the number and scope of all new ELF
core note sections being added, the probable elements there in
can be listed as below.
Changed ELF core note sections
------------------------------
These core note sections need to be changed to accommodate the in
transaction ptrace requests when the running/current value of these
registers will reside some where else instead of the original places
of thread_struct.
/* Running register state */
(1) NT_PRFPREG (Accessible always)
(2) NT_PPC_VMX (Accessible always)
(3) NT_PPC_VSX (Accessible always)
New ELF core note sections
--------------------------
/* TM check pointed register set */
(1) NT_PPC_TM_CGPR --> NT_PRSTATUS (Accessible inside TM)
(2) NT_PPC_TM_CFPR --> NT_PRFPREG (Accessible inside TM)
(3) NT_PPC_TM_CVMX --> NT_PPC_VMX (Accessible inside TM)
(4) NT_PPC_TM_CVSX --> NT_PPC_VSX (Accessible inside TM)
NOTE: The register set data structure for these ELF core not
sections would exactly match with that of the corresponding
running value register sets indicated above.
/* TM SPR set */ (Accessible always)
(5) NT_PPC_TM_SPR thread->tm_tfhar
thread->tm_tfiar
thread->ttm_exasr
/* TM check pointed misc register set */
(6) NT_PPC_TM_TAR thread->tm_tar (Accessible inside TM)
(7) NT_PPC_TM_PPR thread->tm_ppr (Accessible inside TM)
(8) NT_PPC_TM_DSCR thread->tm_dscr (Accessible inside TM)
NOTE: Application can have a different set of TAR, PPR and DSCR
registers inside the transaction compared that of the outside.
Also seems like they are *not* the check pointed ones, will
double check on this. Changed the core note section name from
NT_PPC_TM_CTAR to just NT_PPC_TM_TAR and for all the others.
/* Running misc register set */
(9) NT_PPC_TAR thread->tar (Accessible always)
(10) NT_PPC_PPR thread->ppr (Accessible always)
(11) NT_PPC_DSCR thread->dscr (Accessible always)
NOTE: They are like any other special purpose register which can
be changed from the user space. So the elf core note section name
can be generic. Here are some optional ELF core note sections
which we can also add like the above ones.
(12) NT_PPC_EBBRR thread->ebbrr (Accessible inside EBB)
(13) NT_PPC_EBBHR thread->ebbhr (Accessible inside EBB)
(14) NT_PPC_BESCR thread->bescr (Accessible inside EBB)
(15) NT_PPC_SIAR thread->siar (Accessible inside EBB)
(16) NT_PPC_SDAR thread->sdar (Accessible inside EBB)
(17) NT_PPC_SIER thread->sier (Accessible inside EBB)
(18) NT_PPC_MMCR2 thread->mmcr2 (Accessible inside EBB)
(19) NT_PPC_MMCR0 thread->mmcr0 (Accessible inside EBB)
Ulrich, Mikey, MPE,
Please do let me know your thoughts on this.
Regards
Anshuman
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-21 4:55 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-21 4:55 UTC (permalink / raw)
To: Ulrich Weigand
Cc: Michael Neuling, james.hogan, avagin, Paul.Clothier, peterz,
palves, Edjunior Barbosa Machado, shuahkh, akpm, linux-kernel,
dhowells, linuxppc-dev, kirjanov, oleg, davej, tglx, sukadev,
davem, sam.bobroff
On 04/20/2015 05:57 PM, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 13.04.2015
> 10:48:57:
>> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
>>> - You provide checkpointed FPR and VMX registers, but there doesn't
> seem
>>> to be any way to get at the checkpointed *VSX* registers (i.e. the
> part
>>> that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
>>
>> Will change vsr_get, vsr_set functions as we have done for fpr_get and
> fpr_set
>> functions. Also will add one more ELF core note NT_PPC_TM_CVSX to fetch
> the
>> check pointed state of VSX register while inside the transaction.
>
> OK.
>
>>> I would much prefer three separate regsets (e.g. NT_PPC_DSCR,
> NT_PPC_PPR,
>>> and NT_PPC_TAR), each of which is available and valid if and only if
> the
>>> current processor actually has the register in question.
>>
>> Thats like adding one ELF core note for every single register
>> because we cannot
>> put them in any category. Then as Michael Ellerman had pointed out to
> include
>> a lot more registers in this MISC category (which we are not doing right
> now
>> in the interest of having minimum support available before we look at the
> full
>> possible list of MISC registers), we should add one ELF core note section
> for
>> each of those individual registers ? I am not sure.
>
> This confuses me a bit. My understanding was that ptrace regsets, once
> defined, should never change in the future. (GDB will only check whether
> or not a regset is supported; if it is, it will expect the contents to be
> as it expects them to be.) "Including a lot more registers" would
> therefore
> seem to require adding new regsets anyway, which is one of the reasons why
> I disagree a "MISC" regset is particularly useful.
Yeah right. Started thinking that (NT_PPC_TAR, NT_PPC_CTAR),
(NT_PPC_PPR, NT_PPC_CPPR), (NT_PPC_DSCR, NT_PPC_CDSCR) kind of combinations
make more sense !
>
>>> - Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
>>> matches
>>> registers with different "lifetimes". The transactional memory
> registers
>>> (TFHAR, TEXASR, TFIAR) are available *always* on machines that
> support
>>> transactions. But the other registers in that regset are
> checkpointed
>>> versions that are only available/valid within a transaction. I think
> a
>>> better way to faithfully represent this would be to have the
>>> NT_PPC_TM_SPR
>>> regset only contain the transcational memory registers, and use
> separate
>>> regsets for the checkpointed registers -- those should parallel the
> non-
>>> checkpointed register regset.
>>
>> Right now, we support NT_PPC_TM_SPR only inside the transaction, so we
> dont
>> have the problem with different "lifetimes" registers accessed together.
> But
>> yes, I get your point.
>
> Since the transactional SPRs are accessible from user space outside of a
> transaction, it would make sense for them to accessible from ptrace as
> well.
> If the current patch set doesn't do that, I guess it would be better to
> change that.
Yeah I agree. Will change it.
>
>>> - Particularly confusing to me is the "checkpointed original MSR" which
>>> currently also resides in NT_PPC_TM_SPR. What exactly is this? How
>>> does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
>>
>> I believed it stores the check pointed MSR value which was in the
> register
>> before the transaction started. But then how it is different from the
>> ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
>> more on this. I can see "orig_msr" getting used in many places to hold
> the
>> check pointed value of MSR.
>
> Your other mail states that the orig_mst may be irrelevant for ptrace
> anyway ... that would be OK with me as well.
Yeah. The variable tm_orig_msr is used to compute MSR state inside
the kernel or what would be passed to the user space while returning
at various stages of the transaction, where as ckpt_regs.msr contains
the latest check pointed MSR value to be fetched by ptrace. Thats my
understanding as of now.
>
>>> In any case, it seems the ptrace set-register case currently allows
> user
>>> space to restore *any* arbitrary value into the checkpointed MSR,
> which
>>> would presumably get restored into the real MSR at some point, unless
> I'm
>>> missing something here. Do we not need a check that only safe bits
> are
>>> modified, just like with ptrace access to the real MSR?
>>
>> Where and which safe bits do we check before writing any value into the
> MSR
>> register from ptrace interface ? May be I am missing something here.
>
> All ptrace accesses to *set* the regular msr go via this routine:
>
> static int set_user_msr(struct task_struct *task, unsigned long msr)
> {
> task->thread.regs->msr &= ~MSR_DEBUGCHANGE;
> task->thread.regs->msr |= msr & MSR_DEBUGCHANGE;
> return 0;
> }
>
> I think we'd need to do the equivalent whenever changing the checkpointed
> MSR.
Agree, will incorporate this change.
In summary, after putting together all the issues that we have
discussed till now regarding the number and scope of all new ELF
core note sections being added, the probable elements there in
can be listed as below.
Changed ELF core note sections
------------------------------
These core note sections need to be changed to accommodate the in
transaction ptrace requests when the running/current value of these
registers will reside some where else instead of the original places
of thread_struct.
/* Running register state */
(1) NT_PRFPREG (Accessible always)
(2) NT_PPC_VMX (Accessible always)
(3) NT_PPC_VSX (Accessible always)
New ELF core note sections
--------------------------
/* TM check pointed register set */
(1) NT_PPC_TM_CGPR --> NT_PRSTATUS (Accessible inside TM)
(2) NT_PPC_TM_CFPR --> NT_PRFPREG (Accessible inside TM)
(3) NT_PPC_TM_CVMX --> NT_PPC_VMX (Accessible inside TM)
(4) NT_PPC_TM_CVSX --> NT_PPC_VSX (Accessible inside TM)
NOTE: The register set data structure for these ELF core not
sections would exactly match with that of the corresponding
running value register sets indicated above.
/* TM SPR set */ (Accessible always)
(5) NT_PPC_TM_SPR thread->tm_tfhar
thread->tm_tfiar
thread->ttm_exasr
/* TM check pointed misc register set */
(6) NT_PPC_TM_TAR thread->tm_tar (Accessible inside TM)
(7) NT_PPC_TM_PPR thread->tm_ppr (Accessible inside TM)
(8) NT_PPC_TM_DSCR thread->tm_dscr (Accessible inside TM)
NOTE: Application can have a different set of TAR, PPR and DSCR
registers inside the transaction compared that of the outside.
Also seems like they are *not* the check pointed ones, will
double check on this. Changed the core note section name from
NT_PPC_TM_CTAR to just NT_PPC_TM_TAR and for all the others.
/* Running misc register set */
(9) NT_PPC_TAR thread->tar (Accessible always)
(10) NT_PPC_PPR thread->ppr (Accessible always)
(11) NT_PPC_DSCR thread->dscr (Accessible always)
NOTE: They are like any other special purpose register which can
be changed from the user space. So the elf core note section name
can be generic. Here are some optional ELF core note sections
which we can also add like the above ones.
(12) NT_PPC_EBBRR thread->ebbrr (Accessible inside EBB)
(13) NT_PPC_EBBHR thread->ebbhr (Accessible inside EBB)
(14) NT_PPC_BESCR thread->bescr (Accessible inside EBB)
(15) NT_PPC_SIAR thread->siar (Accessible inside EBB)
(16) NT_PPC_SDAR thread->sdar (Accessible inside EBB)
(17) NT_PPC_SIER thread->sier (Accessible inside EBB)
(18) NT_PPC_MMCR2 thread->mmcr2 (Accessible inside EBB)
(19) NT_PPC_MMCR0 thread->mmcr0 (Accessible inside EBB)
Ulrich, Mikey, MPE,
Please do let me know your thoughts on this.
Regards
Anshuman
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-21 4:55 ` Anshuman Khandual
@ 2015-04-21 14:41 ` Ulrich Weigand
-1 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-21 14:41 UTC (permalink / raw)
To: Anshuman Khandual
Cc: akpm, avagin, davej, davem, dhowells, Edjunior Barbosa Machado,
james.hogan, kirjanov, linux-kernel, linuxppc-dev,
Michael Neuling, oleg, palves, Paul.Clothier, peterz,
sam.bobroff, shuahkh, sukadev, tglx
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 21.04.2015
06:55:24:
> Changed ELF core note sections
> ------------------------------
> These core note sections need to be changed to accommodate the in
> transaction ptrace requests when the running/current value of these
> registers will reside some where else instead of the original places
> of thread_struct.
>
> /* Running register state */
> (1) NT_PRFPREG (Accessible always)
> (2) NT_PPC_VMX (Accessible always)
> (3) NT_PPC_VSX (Accessible always)
>
> New ELF core note sections
> --------------------------
> /* TM check pointed register set */
> (1) NT_PPC_TM_CGPR --> NT_PRSTATUS (Accessible inside TM)
> (2) NT_PPC_TM_CFPR --> NT_PRFPREG (Accessible inside TM)
> (3) NT_PPC_TM_CVMX --> NT_PPC_VMX (Accessible inside TM)
> (4) NT_PPC_TM_CVSX --> NT_PPC_VSX (Accessible inside TM)
>
> NOTE: The register set data structure for these ELF core not
> sections would exactly match with that of the corresponding
> running value register sets indicated above.
OK.
> /* TM SPR set */ (Accessible always)
> (5) NT_PPC_TM_SPR thread->tm_tfhar
> thread->tm_tfiar
> thread->ttm_exasr
OK.
> /* TM check pointed misc register set */
> (6) NT_PPC_TM_TAR thread->tm_tar (Accessible inside TM)
> (7) NT_PPC_TM_PPR thread->tm_ppr (Accessible inside TM)
> (8) NT_PPC_TM_DSCR thread->tm_dscr (Accessible inside TM)
>
> NOTE: Application can have a different set of TAR, PPR and DSCR
> registers inside the transaction compared that of the outside.
> Also seems like they are *not* the check pointed ones, will
> double check on this. Changed the core note section name from
> NT_PPC_TM_CTAR to just NT_PPC_TM_TAR and for all the others.
Huh? How is this not the checkpointed set? I would have
expected that NT_PPC_TAR contains the current tar (which is
the one in the transaction if we're within one), while
NT_PPC_TM_CTAR contains the checkpointed value that will be
restored once the transaction aborts. Why is this not the
case?
> NOTE: They are like any other special purpose register which can
> be changed from the user space. So the elf core note section name
> can be generic. Here are some optional ELF core note sections
> which we can also add like the above ones.
>
> (12) NT_PPC_EBBRR thread->ebbrr (Accessible inside EBB)
> (13) NT_PPC_EBBHR thread->ebbhr (Accessible inside EBB)
> (14) NT_PPC_BESCR thread->bescr (Accessible inside EBB)
> (15) NT_PPC_SIAR thread->siar (Accessible inside EBB)
> (16) NT_PPC_SDAR thread->sdar (Accessible inside EBB)
> (17) NT_PPC_SIER thread->sier (Accessible inside EBB)
> (18) NT_PPC_MMCR2 thread->mmcr2 (Accessible inside EBB)
> (19) NT_PPC_MMCR0 thread->mmcr0 (Accessible inside EBB)
So I'm not really familiar with the EBB stuff. But just as a
general note, if those are in fact related (i.e. on every machine
that has EBB, all those registers will be available), it might
indeed make more sense to collect them into a single note section
(NT_PPC_EBB?) after all.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-21 14:41 ` Ulrich Weigand
0 siblings, 0 replies; 80+ messages in thread
From: Ulrich Weigand @ 2015-04-21 14:41 UTC (permalink / raw)
To: Anshuman Khandual
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 21.04.2015
06:55:24:
> Changed ELF core note sections
> ------------------------------
> These core note sections need to be changed to accommodate the in
> transaction ptrace requests when the running/current value of these
> registers will reside some where else instead of the original places
> of thread_struct.
>
> /* Running register state */
> (1) NT_PRFPREG (Accessible always)
> (2) NT_PPC_VMX (Accessible always)
> (3) NT_PPC_VSX (Accessible always)
>
> New ELF core note sections
> --------------------------
> /* TM check pointed register set */
> (1) NT_PPC_TM_CGPR --> NT_PRSTATUS (Accessible inside TM)
> (2) NT_PPC_TM_CFPR --> NT_PRFPREG (Accessible inside TM)
> (3) NT_PPC_TM_CVMX --> NT_PPC_VMX (Accessible inside TM)
> (4) NT_PPC_TM_CVSX --> NT_PPC_VSX (Accessible inside TM)
>
> NOTE: The register set data structure for these ELF core not
> sections would exactly match with that of the corresponding
> running value register sets indicated above.
OK.
> /* TM SPR set */ (Accessible always)
> (5) NT_PPC_TM_SPR thread->tm_tfhar
> thread->tm_tfiar
> thread->ttm_exasr
OK.
> /* TM check pointed misc register set */
> (6) NT_PPC_TM_TAR thread->tm_tar (Accessible inside TM)
> (7) NT_PPC_TM_PPR thread->tm_ppr (Accessible inside TM)
> (8) NT_PPC_TM_DSCR thread->tm_dscr (Accessible inside TM)
>
> NOTE: Application can have a different set of TAR, PPR and DSCR
> registers inside the transaction compared that of the outside.
> Also seems like they are *not* the check pointed ones, will
> double check on this. Changed the core note section name from
> NT_PPC_TM_CTAR to just NT_PPC_TM_TAR and for all the others.
Huh? How is this not the checkpointed set? I would have
expected that NT_PPC_TAR contains the current tar (which is
the one in the transaction if we're within one), while
NT_PPC_TM_CTAR contains the checkpointed value that will be
restored once the transaction aborts. Why is this not the
case?
> NOTE: They are like any other special purpose register which can
> be changed from the user space. So the elf core note section name
> can be generic. Here are some optional ELF core note sections
> which we can also add like the above ones.
>
> (12) NT_PPC_EBBRR thread->ebbrr (Accessible inside EBB)
> (13) NT_PPC_EBBHR thread->ebbhr (Accessible inside EBB)
> (14) NT_PPC_BESCR thread->bescr (Accessible inside EBB)
> (15) NT_PPC_SIAR thread->siar (Accessible inside EBB)
> (16) NT_PPC_SDAR thread->sdar (Accessible inside EBB)
> (17) NT_PPC_SIER thread->sier (Accessible inside EBB)
> (18) NT_PPC_MMCR2 thread->mmcr2 (Accessible inside EBB)
> (19) NT_PPC_MMCR0 thread->mmcr0 (Accessible inside EBB)
So I'm not really familiar with the EBB stuff. But just as a
general note, if those are in fact related (i.e. on every machine
that has EBB, all those registers will be available), it might
indeed make more sense to collect them into a single note section
(NT_PPC_EBB?) after all.
Bye,
Ulrich
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
2015-04-21 14:41 ` Ulrich Weigand
@ 2015-04-22 9:24 ` Anshuman Khandual
-1 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-22 9:24 UTC (permalink / raw)
To: Ulrich Weigand
Cc: shuahkh, Michael Neuling, james.hogan, avagin, Paul.Clothier,
peterz, palves, linux-kernel, davem, dhowells, linuxppc-dev,
kirjanov, tglx, oleg, davej, akpm, sukadev,
Edjunior Barbosa Machado, sam.bobroff
On 04/21/2015 08:11 PM, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 21.04.2015
> 06:55:24:
>
>> Changed ELF core note sections
>> ------------------------------
>> These core note sections need to be changed to accommodate the in
>> transaction ptrace requests when the running/current value of these
>> registers will reside some where else instead of the original places
>> of thread_struct.
>>
>> /* Running register state */
>> (1) NT_PRFPREG (Accessible always)
>> (2) NT_PPC_VMX (Accessible always)
>> (3) NT_PPC_VSX (Accessible always)
>>
>> New ELF core note sections
>> --------------------------
>> /* TM check pointed register set */
>> (1) NT_PPC_TM_CGPR --> NT_PRSTATUS (Accessible inside TM)
>> (2) NT_PPC_TM_CFPR --> NT_PRFPREG (Accessible inside TM)
>> (3) NT_PPC_TM_CVMX --> NT_PPC_VMX (Accessible inside TM)
>> (4) NT_PPC_TM_CVSX --> NT_PPC_VSX (Accessible inside TM)
>>
>> NOTE: The register set data structure for these ELF core not
>> sections would exactly match with that of the corresponding
>> running value register sets indicated above.
>
> OK.
>
>> /* TM SPR set */ (Accessible always)
>> (5) NT_PPC_TM_SPR thread->tm_tfhar
>> thread->tm_tfiar
>> thread->ttm_exasr
>
> OK.
>
>> /* TM check pointed misc register set */
>> (6) NT_PPC_TM_TAR thread->tm_tar (Accessible inside TM)
>> (7) NT_PPC_TM_PPR thread->tm_ppr (Accessible inside TM)
>> (8) NT_PPC_TM_DSCR thread->tm_dscr (Accessible inside TM)
>>
>> NOTE: Application can have a different set of TAR, PPR and DSCR
>> registers inside the transaction compared that of the outside.
>> Also seems like they are *not* the check pointed ones, will
>> double check on this. Changed the core note section name from
>> NT_PPC_TM_CTAR to just NT_PPC_TM_TAR and for all the others.
>
> Huh? How is this not the checkpointed set? I would have
> expected that NT_PPC_TAR contains the current tar (which is
> the one in the transaction if we're within one), while
> NT_PPC_TM_CTAR contains the checkpointed value that will be
> restored once the transaction aborts. Why is this not the
> case?
Yeah you are right. There is one running value always which is
'thread->tm_tar' when TM is active and it is 'thread->tar' when
TM is not active. This can be accessed *always* with NT_PPC_TAR.
The check pointed TAR is 'thread->tar' only when *TM is active*
which can be accessed via NT_PPC_TM_CTAR. Will update the ELF
core note list with lifetimes.
>
>> NOTE: They are like any other special purpose register which can
>> be changed from the user space. So the elf core note section name
>> can be generic. Here are some optional ELF core note sections
>> which we can also add like the above ones.
>>
>> (12) NT_PPC_EBBRR thread->ebbrr (Accessible inside EBB)
>> (13) NT_PPC_EBBHR thread->ebbhr (Accessible inside EBB)
>> (14) NT_PPC_BESCR thread->bescr (Accessible inside EBB)
>> (15) NT_PPC_SIAR thread->siar (Accessible inside EBB)
>> (16) NT_PPC_SDAR thread->sdar (Accessible inside EBB)
>> (17) NT_PPC_SIER thread->sier (Accessible inside EBB)
>> (18) NT_PPC_MMCR2 thread->mmcr2 (Accessible inside EBB)
>> (19) NT_PPC_MMCR0 thread->mmcr0 (Accessible inside EBB)
>
> So I'm not really familiar with the EBB stuff. But just as a
> general note, if those are in fact related (i.e. on every machine
> that has EBB, all those registers will be available), it might
> indeed make more sense to collect them into a single note section
> (NT_PPC_EBB?) after all.
I agree that would save us precious ELF core note section entry slots
which are 256 in total ever for powerpc arch. Right now all these
register states in thread_struct are getting used for EBB only. But
again these are PMU related registers, in future we may need to access
them for purposes other than EBB. Yes, that will be a problem for us
to solve later on. Right now it makes more sense to group them together
under EBB heading and pass them as a group which saves ELF core note
entries for powerpc. Hopefully Mikey and Michael will agree on this.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
@ 2015-04-22 9:24 ` Anshuman Khandual
0 siblings, 0 replies; 80+ messages in thread
From: Anshuman Khandual @ 2015-04-22 9:24 UTC (permalink / raw)
To: Ulrich Weigand
Cc: Michael Neuling, james.hogan, avagin, Paul.Clothier, peterz,
palves, Edjunior Barbosa Machado, shuahkh, akpm, linux-kernel,
dhowells, linuxppc-dev, kirjanov, oleg, davej, tglx, sukadev,
davem, sam.bobroff
On 04/21/2015 08:11 PM, Ulrich Weigand wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 21.04.2015
> 06:55:24:
>
>> Changed ELF core note sections
>> ------------------------------
>> These core note sections need to be changed to accommodate the in
>> transaction ptrace requests when the running/current value of these
>> registers will reside some where else instead of the original places
>> of thread_struct.
>>
>> /* Running register state */
>> (1) NT_PRFPREG (Accessible always)
>> (2) NT_PPC_VMX (Accessible always)
>> (3) NT_PPC_VSX (Accessible always)
>>
>> New ELF core note sections
>> --------------------------
>> /* TM check pointed register set */
>> (1) NT_PPC_TM_CGPR --> NT_PRSTATUS (Accessible inside TM)
>> (2) NT_PPC_TM_CFPR --> NT_PRFPREG (Accessible inside TM)
>> (3) NT_PPC_TM_CVMX --> NT_PPC_VMX (Accessible inside TM)
>> (4) NT_PPC_TM_CVSX --> NT_PPC_VSX (Accessible inside TM)
>>
>> NOTE: The register set data structure for these ELF core not
>> sections would exactly match with that of the corresponding
>> running value register sets indicated above.
>
> OK.
>
>> /* TM SPR set */ (Accessible always)
>> (5) NT_PPC_TM_SPR thread->tm_tfhar
>> thread->tm_tfiar
>> thread->ttm_exasr
>
> OK.
>
>> /* TM check pointed misc register set */
>> (6) NT_PPC_TM_TAR thread->tm_tar (Accessible inside TM)
>> (7) NT_PPC_TM_PPR thread->tm_ppr (Accessible inside TM)
>> (8) NT_PPC_TM_DSCR thread->tm_dscr (Accessible inside TM)
>>
>> NOTE: Application can have a different set of TAR, PPR and DSCR
>> registers inside the transaction compared that of the outside.
>> Also seems like they are *not* the check pointed ones, will
>> double check on this. Changed the core note section name from
>> NT_PPC_TM_CTAR to just NT_PPC_TM_TAR and for all the others.
>
> Huh? How is this not the checkpointed set? I would have
> expected that NT_PPC_TAR contains the current tar (which is
> the one in the transaction if we're within one), while
> NT_PPC_TM_CTAR contains the checkpointed value that will be
> restored once the transaction aborts. Why is this not the
> case?
Yeah you are right. There is one running value always which is
'thread->tm_tar' when TM is active and it is 'thread->tar' when
TM is not active. This can be accessed *always* with NT_PPC_TAR.
The check pointed TAR is 'thread->tar' only when *TM is active*
which can be accessed via NT_PPC_TM_CTAR. Will update the ELF
core note list with lifetimes.
>
>> NOTE: They are like any other special purpose register which can
>> be changed from the user space. So the elf core note section name
>> can be generic. Here are some optional ELF core note sections
>> which we can also add like the above ones.
>>
>> (12) NT_PPC_EBBRR thread->ebbrr (Accessible inside EBB)
>> (13) NT_PPC_EBBHR thread->ebbhr (Accessible inside EBB)
>> (14) NT_PPC_BESCR thread->bescr (Accessible inside EBB)
>> (15) NT_PPC_SIAR thread->siar (Accessible inside EBB)
>> (16) NT_PPC_SDAR thread->sdar (Accessible inside EBB)
>> (17) NT_PPC_SIER thread->sier (Accessible inside EBB)
>> (18) NT_PPC_MMCR2 thread->mmcr2 (Accessible inside EBB)
>> (19) NT_PPC_MMCR0 thread->mmcr0 (Accessible inside EBB)
>
> So I'm not really familiar with the EBB stuff. But just as a
> general note, if those are in fact related (i.e. on every machine
> that has EBB, all those registers will be available), it might
> indeed make more sense to collect them into a single note section
> (NT_PPC_EBB?) after all.
I agree that would save us precious ELF core note section entry slots
which are 256 in total ever for powerpc arch. Right now all these
register states in thread_struct are getting used for EBB only. But
again these are PMU related registers, in future we may need to access
them for purposes other than EBB. Yes, that will be a problem for us
to solve later on. Right now it makes more sense to group them together
under EBB heading and pass them as a group which saves ELF core note
entries for powerpc. Hopefully Mikey and Michael will agree on this.
^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2015-04-22 9:25 UTC | newest]
Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-02 7:56 [PATCH V6 0/9] Add new powerpc specific ELF core notes Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 1/9] elf: Add new powerpc specifc core note sections Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-03 5:22 ` [V6,1/9] " Michael Ellerman
2014-12-03 5:22 ` Michael Ellerman
2014-12-03 6:48 ` Anshuman Khandual
2014-12-03 6:48 ` Anshuman Khandual
2014-12-08 10:08 ` Anshuman Khandual
2014-12-08 10:08 ` Anshuman Khandual
2014-12-19 19:28 ` Edjunior Barbosa Machado
2014-12-19 19:28 ` Edjunior Barbosa Machado
2015-01-01 8:08 ` Anshuman Khandual
2015-01-01 8:08 ` Anshuman Khandual
2015-01-14 4:44 ` Anshuman Khandual
2015-01-14 4:44 ` Anshuman Khandual
2015-01-21 23:39 ` Michael Neuling
2015-01-21 23:39 ` Michael Neuling
2015-01-22 15:55 ` Ulrich Weigand
2015-01-22 15:55 ` Ulrich Weigand
2015-01-22 21:44 ` Michael Neuling
2015-01-22 21:44 ` Michael Neuling
2015-01-28 4:28 ` Michael Neuling
2015-01-28 4:28 ` Michael Neuling
2015-02-06 14:47 ` Ulrich Weigand
2015-02-06 14:47 ` Ulrich Weigand
2015-02-23 4:51 ` Michael Neuling
2015-02-23 4:51 ` Michael Neuling
2015-03-18 12:53 ` Ulrich Weigand
2015-03-18 12:53 ` Ulrich Weigand
2015-03-18 22:45 ` Michael Neuling
2015-03-18 22:45 ` Michael Neuling
2015-03-18 22:50 ` Michael Neuling
2015-03-18 22:50 ` Michael Neuling
2015-03-23 10:34 ` Anshuman Khandual
2015-03-23 10:34 ` Anshuman Khandual
2015-04-08 17:50 ` Ulrich Weigand
2015-04-08 17:50 ` Ulrich Weigand
2015-04-08 23:11 ` Michael Neuling
2015-04-08 23:11 ` Michael Neuling
2015-04-09 12:50 ` Anshuman Khandual
2015-04-09 12:50 ` Anshuman Khandual
2015-04-10 3:03 ` Michael Neuling
2015-04-10 3:03 ` Michael Neuling
2015-04-10 9:10 ` Anshuman Khandual
2015-04-10 9:10 ` Anshuman Khandual
2015-04-10 10:33 ` Ulrich Weigand
2015-04-10 10:33 ` Ulrich Weigand
2015-04-13 8:48 ` Anshuman Khandual
2015-04-13 8:48 ` Anshuman Khandual
2015-04-20 6:42 ` Anshuman Khandual
2015-04-20 6:42 ` Anshuman Khandual
2015-04-20 12:27 ` Ulrich Weigand
2015-04-20 12:27 ` Ulrich Weigand
2015-04-21 4:55 ` Anshuman Khandual
2015-04-21 4:55 ` Anshuman Khandual
2015-04-21 14:41 ` Ulrich Weigand
2015-04-21 14:41 ` Ulrich Weigand
2015-04-22 9:24 ` Anshuman Khandual
2015-04-22 9:24 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 2/9] powerpc, process: Add the function flush_tmregs_to_thread Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 3/9] powerpc, ptrace: Enable fpr_(get/set) for transactional memory Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 4/9] powerpc, ptrace: Enable vr_(get/set) " Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 5/9] powerpc, ptrace: Enable support for transactional memory register sets Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 6/9] powerpc, ptrace: Enable support for miscellaneous debug registers Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 7/9] selftests, powerpc: Add test case for TM related ptrace interface Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 8/9] selftests, powerpc: Make GIT ignore all binaries related to TM Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite Anshuman Khandual
2014-12-02 7:56 ` Anshuman Khandual
2014-12-02 18:23 ` Shuah Khan
2014-12-02 18:23 ` Shuah Khan
2014-12-03 5:46 ` Anshuman Khandual
2014-12-03 5:46 ` Anshuman Khandual
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.