From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B0C4C43441 for ; Wed, 28 Nov 2018 03:36:15 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1A2F92086B for ; Wed, 28 Nov 2018 03:36:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A2F92086B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 434RC11HsSzDqRn for ; Wed, 28 Nov 2018 14:36:13 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 434R8g44MvzDqQ9 for ; Wed, 28 Nov 2018 14:34:11 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 434R8g07ZPz9s2P; Wed, 28 Nov 2018 14:34:11 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Arnaldo Carvalho de Melo , Madhavan Srinivasan Subject: Re: [PATCH RESEND] powerpc/perf: Update perf_regs structure to include SIER In-Reply-To: <20181126193821.GD18491@kernel.org> References: <1543255448-27552-1-git-send-email-maddy@linux.vnet.ibm.com> <20181126193821.GD18491@kernel.org> Date: Wed, 28 Nov 2018 14:34:10 +1100 Message-ID: <878t1dho3x.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexander Shishkin , linuxppc-dev@lists.ozlabs.org, Thomas Richter , Hendrik Brueckner , Ravi Bangoria , Anju T Sudhakar , Martin Schwidefsky , Namhyung Kim , Jiri Olsa Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Arnaldo Carvalho de Melo writes: > Em Mon, Nov 26, 2018 at 11:34:08PM +0530, Madhavan Srinivasan escreveu: >> On each sample, Sample Instruction Event Register (SIER) content >> is saved in pt_regs. SIER does not have a entry as-is in the pt_regs >> but instead, SIER content is saved in the "dar" register of pt_regs. >> >> Patch adds another entry to the perf_regs structure to include the "SIER" >> printing which internally maps to the "dar" of pt_regs. > > I think the patch is ok, when we talked in Vancouver I thought I saw > something like this before, i.e. adding more registers to a perf_regs.h > file, this was the cset: > > commit 0da0017f72554c005c1a04c3adc5da9eb64fa7e5 > Author: Hendrik Brueckner > Date: Wed Nov 8 07:30:15 2017 +0100 > > s390/perf: extend perf_regs support to include floating-point registers > > That I came across because it broke the perf build, making me add this > cset: > > commit 10b9baa701d5023897f70a4acb3bf0235da3dc4f > Author: Arnaldo Carvalho de Melo > Date: Tue Nov 28 11:08:41 2017 -0300 > > tools arch s390: Do not include header files from the kernel sources > > :-) > > Michael? What about the ppc specific details? The only possible objection is that not all CPUs have an SIER register, so on CPUs without it you'll get the content of the DAR register rather than the SIER (because we (ab)use the DAR slot of pt_regs for the SIER). Perhaps we should make sure that we return 0 on CPUs that don't have the register? cheers