Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934479AbbDVJZ7 (ORCPT ); Wed, 22 Apr 2015 05:25:59 -0400 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:38640 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934462AbbDVJZ5 (ORCPT ); Wed, 22 Apr 2015 05:25:57 -0400 Message-ID: <553768D1.1080208@linux.vnet.ibm.com> Date: Wed, 22 Apr 2015 14:54:33 +0530 From: Anshuman Khandual User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ulrich Weigand CC: shuahkh@osg.samsung.com, Michael Neuling , james.hogan@imgtec.com, avagin@openvz.org, Paul.Clothier@imgtec.com, peterz@infradead.org, palves@redhat.com, linux-kernel@vger.kernel.org, davem@davemloft.net, dhowells@redhat.com, linuxppc-dev@ozlabs.org, kirjanov@gmail.com, tglx@linutronix.de, oleg@redhat.com, davej@redhat.com, akpm@linux-foundation.org, sukadev@linux.vnet.ibm.com, Edjunior Barbosa Machado , sam.bobroff@au1.ibm.com Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections References: <20141203052204.9DA8F1400DD@ozlabs.org> <54A50094.5070902@linux.vnet.ibm.com> <1421883597.30744.3.camel@neuling.org> <1421963049.30744.23.camel@neuling.org> <1422419289.9646.20.camel@neuling.org> <1424667110.16027.6.camel@neuling.org> <1426718702.4866.2.camel@neuling.org> <1426719027.4866.4.camel@neuling.org> <550FEC36.8080803@linux.vnet.ibm.com> <1428534695.4682.18.camel@neuling.org> <55267595.90 <5527938B.1030901@linux.vnet.ibm.com> <552B82F9.3080108@linux.vnet.ibm.com> <5535D83C.1060302@linux.vnet.ibm.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: 15042209-0033-0000-0000-0000015FA7FC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4412 Lines: 97 On 04/21/2015 08:11 PM, Ulrich Weigand wrote: > Anshuman Khandual 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/