Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932438AbbDJKdn (ORCPT ); Fri, 10 Apr 2015 06:33:43 -0400 Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:34969 "EHLO e06smtp12.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753722AbbDJKdl (ORCPT ); Fri, 10 Apr 2015 06:33:41 -0400 In-Reply-To: <5527938B.1030901@linux.vnet.ibm.com> References: <20141203052204.9DA8F1400DD@ozlabs.org> <548578A8.5020901@linux.vnet.ibm.com> <54947C64.4030206@linux.vnet.ibm.com> <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> Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections X-KeepSent: CDE0430E:A5CD2FAF-C1257E23:003813C4; type=4; name=$KeepSent To: Anshuman Khandual Cc: akpm@linux-foundation.org, avagin@openvz.org, davej@redhat.com, davem@davemloft.net, dhowells@redhat.com, Edjunior Barbosa Machado , james.hogan@imgtec.com, kirjanov@gmail.com, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Michael Neuling , oleg@redhat.com, palves@redhat.com, Paul.Clothier@imgtec.com, peterz@infradead.org, sam.bobroff@au1.ibm.com, shuahkh@osg.samsung.com, sukadev@linux.vnet.ibm.com, tglx@linutronix.de X-Mailer: IBM Notes Release 9.0.1FP2 August 03, 2014 Message-ID: From: Ulrich Weigand Date: Fri, 10 Apr 2015 12:33:13 +0200 X-MIMETrack: Serialize by Router on D06ML032/06/M/IBM(Release 9.0.1FP3|January 12, 2015) at 10/04/2015 12:33:35 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15041010-0009-0000-0000-000003C5CD8B Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3193 Lines: 71 Anshuman Khandual 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 -- 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/