From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Ellerman Date: Wed, 22 Jul 2020 12:03:19 +0000 Subject: Re: [v3 04/15] powerpc/perf: Add support for ISA3.1 PMU SPRs Message-Id: <87d04nrc3c.fsf@mpe.ellerman.id.au> List-Id: References: <1594996707-3727-1-git-send-email-atrajeev@linux.vnet.ibm.com> <1594996707-3727-5-git-send-email-atrajeev@linux.vnet.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jordan Niethe , Athira Rajeev Cc: Gautham R Shenoy , mikey@neuling.org, maddy@linux.vnet.ibm.com, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, svaidyan@in.ibm.com, acme@kernel.org, jolsa@kernel.org, linuxppc-dev Jordan Niethe writes: > On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev wrote: >> From: Madhavan Srinivasan >> >> PowerISA v3.1 includes new performance monitoring unit(PMU) >> special purpose registers (SPRs). They are ... >> >> diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h >> index 14b8dc1..832450a 100644 >> --- a/arch/powerpc/include/asm/perf_event_server.h >> +++ b/arch/powerpc/include/asm/perf_event_server.h >> @@ -75,6 +76,7 @@ struct power_pmu { >> #define PPMU_HAS_SIER 0x00000040 /* Has SIER */ >> #define PPMU_ARCH_207S 0x00000080 /* PMC is architecture v2.07S */ >> #define PPMU_NO_SIAR 0x00000100 /* Do not use SIAR */ >> +#define PPMU_ARCH_310S 0x00000200 /* Has MMCR3, SIER2 and SIER3 */ > We elsewhere have CPU_FTR_ARCH_31, so should this be PPMU_ARCH_31S to > be consistent. The "S" is no longer needed as there's no Book S vs Book E distinction in ISA v3.1. So I changed it to PPMU_ARCH_31. >> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c >> index f4d07b5..ca32fc0 100644 >> --- a/arch/powerpc/perf/core-book3s.c >> +++ b/arch/powerpc/perf/core-book3s.c >> @@ -581,6 +589,11 @@ static void ebb_switch_out(unsigned long mmcr0) >> current->thread.sdar = mfspr(SPRN_SDAR); >> current->thread.mmcr0 = mmcr0 & MMCR0_USER_MASK; >> current->thread.mmcr2 = mfspr(SPRN_MMCR2) & MMCR2_USER_MASK; >> + if (ppmu->flags & PPMU_ARCH_310S) { >> + current->thread.mmcr3 = mfspr(SPRN_MMCR3); > Like MMCR0_USER_MASK and MMCR2_USER_MASK do we need a MMCR3_USER_MASK > here, or is there no need? mmcr0 and mmcr2 are visible via ptrace, so masking them here means we don't expose any bits to userspace via ptrace that aren't also visible by reading the register. So at least while mmcr3 is not exposed via ptrace it's safe to not mask it, if there are even any sensitive bits in it. cheers 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=-7.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 748CBC433E1 for ; Wed, 22 Jul 2020 12:05:05 +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 E132A20771 for ; Wed, 22 Jul 2020 12:05:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b="pbJKuaAb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E132A20771 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 bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BBZ0G0n68zDr74 for ; Wed, 22 Jul 2020 22:05:02 +1000 (AEST) Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BBYyM5bkBzDr2P for ; Wed, 22 Jul 2020 22:03:23 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=pbJKuaAb; dkim-atps=neutral Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4BBYyM02F6z9sPf; Wed, 22 Jul 2020 22:03:22 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1595419403; bh=ZYxAwsh+3V5ye+dbkADhu2jHGiIvpQV3pkw5+1n3oQ4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pbJKuaAbmKMnTeSJtpm/DmRD0ObL6TwDoH5YKVdk177dIMEO3tiudGi2nfK4T1nGC IEGLosv3KFMK582kcIoHGZqOsxpq5V3/V5oTOHNL4VtyaEflh9c1+1O2OuQqi+ShRA 1dzO0TPYEYCY2av4+fsq9esViJWyOfQCgEIa5yrWoBiui7Haa8VR16wV3Lg0tmOUts o8KQyfOsD11S8kQ2m+UsCIjtXAYzZ5tm8MItxsKIPAgCT3QZuKwVwNxi6HCk3iS1fe SOpwGxc75kco5+vnZgaymlIE4J7sKjzeMd/N15WclBfP+E/vOZN+lZzvtpDPFLGmya rS+fUezpswXXQ== From: Michael Ellerman To: Jordan Niethe , Athira Rajeev Subject: Re: [v3 04/15] powerpc/perf: Add support for ISA3.1 PMU SPRs In-Reply-To: References: <1594996707-3727-1-git-send-email-atrajeev@linux.vnet.ibm.com> <1594996707-3727-5-git-send-email-atrajeev@linux.vnet.ibm.com> Date: Wed, 22 Jul 2020 22:03:19 +1000 Message-ID: <87d04nrc3c.fsf@mpe.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: Gautham R Shenoy , mikey@neuling.org, maddy@linux.vnet.ibm.com, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, svaidyan@in.ibm.com, acme@kernel.org, jolsa@kernel.org, linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Jordan Niethe writes: > On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev wrote: >> From: Madhavan Srinivasan >> >> PowerISA v3.1 includes new performance monitoring unit(PMU) >> special purpose registers (SPRs). They are ... >> >> diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h >> index 14b8dc1..832450a 100644 >> --- a/arch/powerpc/include/asm/perf_event_server.h >> +++ b/arch/powerpc/include/asm/perf_event_server.h >> @@ -75,6 +76,7 @@ struct power_pmu { >> #define PPMU_HAS_SIER 0x00000040 /* Has SIER */ >> #define PPMU_ARCH_207S 0x00000080 /* PMC is architecture v2.07S */ >> #define PPMU_NO_SIAR 0x00000100 /* Do not use SIAR */ >> +#define PPMU_ARCH_310S 0x00000200 /* Has MMCR3, SIER2 and SIER3 */ > We elsewhere have CPU_FTR_ARCH_31, so should this be PPMU_ARCH_31S to > be consistent. The "S" is no longer needed as there's no Book S vs Book E distinction in ISA v3.1. So I changed it to PPMU_ARCH_31. >> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c >> index f4d07b5..ca32fc0 100644 >> --- a/arch/powerpc/perf/core-book3s.c >> +++ b/arch/powerpc/perf/core-book3s.c >> @@ -581,6 +589,11 @@ static void ebb_switch_out(unsigned long mmcr0) >> current->thread.sdar = mfspr(SPRN_SDAR); >> current->thread.mmcr0 = mmcr0 & MMCR0_USER_MASK; >> current->thread.mmcr2 = mfspr(SPRN_MMCR2) & MMCR2_USER_MASK; >> + if (ppmu->flags & PPMU_ARCH_310S) { >> + current->thread.mmcr3 = mfspr(SPRN_MMCR3); > Like MMCR0_USER_MASK and MMCR2_USER_MASK do we need a MMCR3_USER_MASK > here, or is there no need? mmcr0 and mmcr2 are visible via ptrace, so masking them here means we don't expose any bits to userspace via ptrace that aren't also visible by reading the register. So at least while mmcr3 is not exposed via ptrace it's safe to not mask it, if there are even any sensitive bits in it. cheers