From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752237AbcFFI6P (ORCPT ); Mon, 6 Jun 2016 04:58:15 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:3539 "EHLO mx0b-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751006AbcFFI6L (ORCPT ); Mon, 6 Jun 2016 04:58:11 -0400 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: khandual@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 06 Jun 2016 14:27:11 +0530 From: Anshuman Khandual User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cyril Bur CC: Paul.Clothier@imgtec.com, peterz@infradead.org, linux-kernel@vger.kernel.org, dhowells@redhat.com, linuxppc-dev@ozlabs.org, Michael Neuling , shuahkh@osg.samsung.com, kirjanov@gmail.com, sukadev@linux.vnet.ibm.com, james.hogan@imgtec.com, Ulrich.Weigand@de.ibm.com, davej@redhat.com, tglx@linutronix.de, avagin@openvz.org, palves@redhat.com, oleg@redhat.com, davem@davemloft.net, Andrew Morton , Laurent Dufour , emachado@linux.vnet.ibm.com, sam.bobroff@au1.ibm.com Subject: Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes References: <1455613198-5113-1-git-send-email-khandual@linux.vnet.ibm.com> <57062722.5090706@linux.vnet.ibm.com> <5EA48413-85A1-4CB7-8843-CE22B2BB1F08@ellerman.id.au> <570B54EB.90507@linux.vnet.ibm.com> <1460524468.30704.5.camel@ellerman.id.au> <5718F901.6010104@linux.vnet.ibm.com> <5748004F.7040408@linux.vnet.ibm.com> <1464649951.16938.5.camel@ellerman.id.au> <201606010827.u518O0bl023243@mx0a-001b2d01.pphosted.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16060608-0008-0000-0000-00000095523C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16060608-0009-0000-0000-00000766C7B6 Message-Id: <57553AE7.3060704@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-06_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606060108 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/03/2016 03:56 AM, Cyril Bur wrote: > On 1 June 2016 at 18:26, Anshuman Khandual > wrote: > >> On 05/31/2016 04:42 AM, Michael Ellerman wrote: >>> Hi Laurent, >>> >>> Sorry no. My next branch closed for 4.7 about 3 weeks ago. >>> >>> This series has been blocked for a long time on the gdb support, but >> that is >>> now working. However it still doesn't pass its own selftests, and I had >> some >> >> This series was clearing all of the selftests at the time it was posted. >> But yes, it has some assumptions from timing and sync perspective which >> gets broken some times as the kernel changes. Its been bit difficult to >> perfect the sync requirements as we can do only some much inside the >> transaction once it gets started. There are scopes here to improve these >> selftests but not clearing them today does not really mean the patches are >> now functionally broken. >> >>> disagreements with the implementation - it duplicates a lot of code >> rather >>> than refactoring things. >> >> hmm, sorry, I dont remember the context here. Can you please point to the >> discussion in this regard ? >> >>> >>> I'm waiting on a patch from Cyril which will rework how the TM FP state >> is >>> handled, and that should make this series easier to implement. >> >> Can you please elaborate on this ? Has this patch been posted in the >> mailing >> list ? How does this make it easier for us to implement these ELF notes ? > > > Hi Anshuman, > > I'm doing a bit of a rewrite of the TM handling of the FP/VMX/VSX state. > > At the moment is is rather confusing since pt_regs is the always the 'live' > state > and theres a ckpt_regs that is the pt_regs for the checkpointed state. > FPU/VMX/VSX > is done differently which is really only creating confusion so I'm changing > it to do the > same at for pt_regs/ckpt_regs. Ultimately this is part of more work from me But that changes the basic semantics on which this ptrace series is written. With this change, a significant part of the ptrace series has to be changed. Its just an improvement on how we store running and check pointed values for FP/VSX/VMX registers inside the kernel. How does it improve ptrace interface from the user point of view ? If not, then why this change is necessary for the acceptance of this patch series ? This change should be implemented as an independent work and then necessary ptrace change can be incorporated there after. > but > Michael has told me that at least this bit is useful now so I'm splitting > it off from > the bigger picture and sending asap. At the very least it will make it > easier to know > what and where the transactional state it and where the checkpointed state > is. > > It isn't on the list but I hope I'll get it out today.