From: Michael Neuling <mikey@neuling•org>
To: Anshuman Khandual <khandual@linux•vnet.ibm.com>
Cc: james.hogan@imgtec•com, avagin@openvz•org,
Paul.Clothier@imgtec•com, davem@davemloft•net,
peterz@infradead•org, Ulrich Weigand <uweigand@de•ibm.com>,
oleg@redhat•com, linux-kernel@vger•kernel.org,
shuahkh@osg•samsung.com, dhowells@redhat•com,
linuxppc-dev@ozlabs•org, kirjanov@gmail•com, tglx@linutronix•de,
palves@redhat•com, davej@redhat•com, akpm@linux-foundation•org,
sukadev@linux•vnet.ibm.com,
Edjunior Barbosa Machado <emachado@linux•vnet.ibm.com>,
sam.bobroff@au1•ibm.com
Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections
Date: Thu, 22 Jan 2015 10:39:57 +1100 [thread overview]
Message-ID: <1421883597.30744.3.camel@neuling.org> (raw)
In-Reply-To: <54A50094.5070902@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2015-01-21 23:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 7:56 [PATCH V6 0/9] Add new powerpc specific ELF core notes Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 1/9] elf: Add new powerpc specifc core note sections Anshuman Khandual
2014-12-03 5:22 ` [V6,1/9] " Michael Ellerman
2014-12-03 6:48 ` Anshuman Khandual
2014-12-08 10:08 ` Anshuman Khandual
2014-12-19 19:28 ` Edjunior Barbosa Machado
2015-01-01 8:08 ` Anshuman Khandual
2015-01-14 4:44 ` Anshuman Khandual
2015-01-21 23:39 ` Michael Neuling [this message]
2015-01-22 15:55 ` Ulrich Weigand
2015-01-22 21:44 ` Michael Neuling
2015-01-28 4:28 ` Michael Neuling
2015-02-06 14:47 ` Ulrich Weigand
2015-02-23 4:51 ` Michael Neuling
2015-03-18 12:53 ` Ulrich Weigand
2015-03-18 22:45 ` Michael Neuling
2015-03-18 22:50 ` Michael Neuling
2015-03-23 10:34 ` Anshuman Khandual
2015-04-08 17:50 ` Ulrich Weigand
2015-04-08 23:11 ` Michael Neuling
2015-04-09 12:50 ` Anshuman Khandual
2015-04-10 3:03 ` Michael Neuling
2015-04-10 9:10 ` Anshuman Khandual
2015-04-10 10:33 ` Ulrich Weigand
2015-04-13 8:48 ` Anshuman Khandual
2015-04-20 6:42 ` Anshuman Khandual
2015-04-20 12:27 ` Ulrich Weigand
2015-04-21 4:55 ` Anshuman Khandual
2015-04-21 14:41 ` Ulrich Weigand
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 ` [PATCH V6 3/9] powerpc, ptrace: Enable fpr_(get/set) for transactional memory Anshuman Khandual
2014-12-02 7:56 ` [PATCH V6 4/9] powerpc, ptrace: Enable vr_(get/set) " 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 ` [PATCH V6 6/9] powerpc, ptrace: Enable support for miscellaneous debug registers 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 ` [PATCH V6 8/9] selftests, powerpc: Make GIT ignore all binaries related to TM 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 18:23 ` Shuah Khan
2014-12-03 5:46 ` Anshuman Khandual
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1421883597.30744.3.camel@neuling.org \
--to=mikey@neuling$(echo .)org \
--cc=Paul.Clothier@imgtec$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=avagin@openvz$(echo .)org \
--cc=davej@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dhowells@redhat$(echo .)com \
--cc=emachado@linux$(echo .)vnet.ibm.com \
--cc=james.hogan@imgtec$(echo .)com \
--cc=khandual@linux$(echo .)vnet.ibm.com \
--cc=kirjanov@gmail$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=oleg@redhat$(echo .)com \
--cc=palves@redhat$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=sam.bobroff@au1$(echo .)ibm.com \
--cc=shuahkh@osg$(echo .)samsung.com \
--cc=sukadev@linux$(echo .)vnet.ibm.com \
--cc=tglx@linutronix$(echo .)de \
--cc=uweigand@de$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox