From: Pedro Alves <palves@redhat.com>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>,
Pedro Alves <palves@redhat.com>
Cc: mikey@neuling.org, avagin@openvz.org, oleg@redhat.com,
linux-kernel@vger.kernel.org, michael@ellerman.id.au,
linuxppc-dev@ozlabs.org
Subject: Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
Date: Wed, 14 May 2014 12:15:16 +0100 [thread overview]
Message-ID: <53735044.5030008@redhat.com> (raw)
In-Reply-To: <53730326.6000400@linux.vnet.ibm.com>
On 05/14/14 06:46, Anshuman Khandual wrote:
> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>> 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
>>
>> Sorry that I couldn't tell this from the code, but, what does the
>> kernel return when the ptracer requests these registers and the
>> program is not in a transaction? Specifically I'm wondering whether
>> this follows the same semantics as the s390 port.
>>
>
> Right now, it still returns the saved state of the registers from thread
> struct. I had assumed that the user must know the state of the transaction
> before initiating the ptrace request. I guess its better to check for
> the transaction status before processing the request. In case if TM is not
> active on that thread, we should return -EINVAL.
I think s390 returns ENODATA in that case.
https://sourceware.org/ml/gdb-patches/2013-06/msg00273.html
We'll want some way to tell whether the system actually
supports this. That could be ENODATA vs something-else (EINVAL
or perhaps better EIO for "request is invalid").
s390 actually screwed that, though it got away because
there's a bit in HWCAP to signal transactions support. See:
https://sourceware.org/ml/gdb-patches/2013-11/msg00080.html
Are you adding something to HWCAP too?
>
> I am not familiar with the s390 side of code. But if we look at the
> s390_tdb_get function it checks for (regs->int_code & 0x200) before
> processing the request. Not sure what 0x200 signifies though.
--
Pedro Alves
WARNING: multiple messages have this Message-ID (diff)
From: Pedro Alves <palves@redhat.com>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>,
Pedro Alves <palves@redhat.com>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
michael@ellerman.id.au, mikey@neuling.org, avagin@openvz.org,
oleg@redhat.com
Subject: Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
Date: Wed, 14 May 2014 12:15:16 +0100 [thread overview]
Message-ID: <53735044.5030008@redhat.com> (raw)
In-Reply-To: <53730326.6000400@linux.vnet.ibm.com>
On 05/14/14 06:46, Anshuman Khandual wrote:
> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>> 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
>>
>> Sorry that I couldn't tell this from the code, but, what does the
>> kernel return when the ptracer requests these registers and the
>> program is not in a transaction? Specifically I'm wondering whether
>> this follows the same semantics as the s390 port.
>>
>
> Right now, it still returns the saved state of the registers from thread
> struct. I had assumed that the user must know the state of the transaction
> before initiating the ptrace request. I guess its better to check for
> the transaction status before processing the request. In case if TM is not
> active on that thread, we should return -EINVAL.
I think s390 returns ENODATA in that case.
https://sourceware.org/ml/gdb-patches/2013-06/msg00273.html
We'll want some way to tell whether the system actually
supports this. That could be ENODATA vs something-else (EINVAL
or perhaps better EIO for "request is invalid").
s390 actually screwed that, though it got away because
there's a bit in HWCAP to signal transactions support. See:
https://sourceware.org/ml/gdb-patches/2013-11/msg00080.html
Are you adding something to HWCAP too?
>
> I am not familiar with the s390 side of code. But if we look at the
> s390_tdb_get function it checks for (regs->int_code & 0x200) before
> processing the request. Not sure what 0x200 signifies though.
--
Pedro Alves
next prev parent reply other threads:[~2014-05-14 11:15 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 7:54 [PATCH V2 0/3] Add new PowerPC specific ELF core notes Anshuman Khandual
2014-05-05 7:54 ` Anshuman Khandual
2014-05-05 7:54 ` [PATCH V2 1/3] elf: Add some new PowerPC specifc note sections Anshuman Khandual
2014-05-05 7:54 ` Anshuman Khandual
2014-05-05 7:54 ` [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets Anshuman Khandual
2014-05-05 7:54 ` Anshuman Khandual
2014-05-13 17:13 ` Pedro Alves
2014-05-14 5:46 ` Anshuman Khandual
2014-05-14 5:46 ` Anshuman Khandual
2014-05-14 11:15 ` Pedro Alves [this message]
2014-05-14 11:15 ` Pedro Alves
2014-05-14 11:18 ` Michael Neuling
2014-05-14 11:22 ` Pedro Alves
2014-05-14 11:22 ` Pedro Alves
2014-05-15 8:25 ` Anshuman Khandual
2014-05-15 8:25 ` Anshuman Khandual
2014-05-15 12:08 ` Pedro Alves
2014-05-15 12:08 ` Pedro Alves
2014-05-16 0:26 ` Michael Neuling
2014-05-16 0:26 ` Michael Neuling
2014-05-19 9:12 ` Anshuman Khandual
2014-05-19 9:12 ` Anshuman Khandual
2014-05-19 11:46 ` Anshuman Khandual
2014-05-19 11:46 ` Anshuman Khandual
2014-05-19 14:43 ` Pedro Alves
2014-05-19 14:43 ` Pedro Alves
2014-05-20 8:14 ` Anshuman Khandual
2014-05-20 8:14 ` Anshuman Khandual
2014-05-20 10:33 ` Pedro Alves
2014-05-20 10:33 ` Pedro Alves
2014-05-22 5:08 ` Anshuman Khandual
2014-05-22 5:08 ` Anshuman Khandual
2014-05-23 13:57 ` Anshuman Khandual
2014-05-23 13:57 ` Anshuman Khandual
2014-05-13 17:21 ` Pedro Alves
2014-05-13 17:21 ` Pedro Alves
2014-05-14 5:49 ` Anshuman Khandual
2014-05-14 5:49 ` Anshuman Khandual
2014-05-22 5:30 ` Michael Ellerman
2014-05-22 5:30 ` Michael Ellerman
2014-05-05 7:54 ` [PATCH V2 3/3] powerpc, ptrace: Enable support for miscellaneous registers Anshuman Khandual
2014-05-05 7:54 ` 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=53735044.5030008@redhat.com \
--to=palves@redhat.com \
--cc=avagin@openvz.org \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael@ellerman.id.au \
--cc=mikey@neuling.org \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.