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=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT 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 90ABEC4360F for ; Thu, 4 Apr 2019 19:34:05 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 647DF20651 for ; Thu, 4 Apr 2019 19:34:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZHQmBc/9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 647DF20651 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2sZCb5egeEjEf6YLmr+FrpCUV89n75OXW98XhB01X64=; b=ZHQmBc/9tXZzVs MfVZEZOFCMi3OuG5DcdVPZGa6LiBQ3Ep8iOvTcimWTbXCj/raiR88JA1YBpdHs5mrplc024HqoCyh TX9In54ddEAzr9972JimxpaWlpjEOAEb2u+RlqG2Jz+Hb2ai97aokH1YR7BK7CZ5XfNND2TP8icXg bOKjt5oqa6WuMRDdclT8nkRK8suZrNUi9LRRy/5p+0ZpJn6q9UfCnswQfrT9G5p0BDGmSuEntIE3f UjDtl8As+nzoKgDRrjjVmPZO7qqOzr1hM6z+4J67hkGAhak7DSRhFjYq2nQvBUUE0mqyVSi5JHCil fOojDQxRxGi2/AUJbdnA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC87c-0006yT-CO; Thu, 04 Apr 2019 19:34:00 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC87Y-0006y4-Ls for linux-arm-kernel@lists.infradead.org; Thu, 04 Apr 2019 19:33:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A0F15168F; Thu, 4 Apr 2019 12:33:53 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 35CDC3F721; Thu, 4 Apr 2019 12:33:53 -0700 (PDT) Date: Thu, 4 Apr 2019 20:33:51 +0100 From: Andrew Murray To: Will Deacon Subject: Re: [PATCH v12 8/8] arm64: docs: document perf event attributes Message-ID: <20190404193350.GP53702@e119886-lin.cambridge.arm.com> References: <20190328103731.27264-1-andrew.murray@arm.com> <20190328103731.27264-9-andrew.murray@arm.com> <20190404162128.GD27577@fuggles.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190404162128.GD27577@fuggles.cambridge.arm.com> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190404_123356_727722_06C68F1C X-CRM114-Status: GOOD ( 30.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Suzuki K Poulose , Marc Zyngier , Catalin Marinas , Julien Thierry , Christoffer Dall , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 04, 2019 at 05:21:28PM +0100, Will Deacon wrote: > On Thu, Mar 28, 2019 at 10:37:31AM +0000, Andrew Murray wrote: > > The interaction between the exclude_{host,guest} flags, > > exclude_{user,kernel,hv} flags and presence of VHE can result in > > different exception levels being filtered by the ARMv8 PMU. As this > > can be confusing let's document how they work on arm64. > > > > Signed-off-by: Andrew Murray > > --- > > Documentation/arm64/perf.txt | 74 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 74 insertions(+) > > create mode 100644 Documentation/arm64/perf.txt > > > > diff --git a/Documentation/arm64/perf.txt b/Documentation/arm64/perf.txt > > new file mode 100644 > > index 000000000000..604446c1f720 > > --- /dev/null > > +++ b/Documentation/arm64/perf.txt > > @@ -0,0 +1,74 @@ > > +Perf Event Attributes > > +===================== > > + > > +Author: Andrew Murray > > +Date: 2019-03-06 > > + > > +exclude_user > > +------------ > > + > > +This attribute excludes userspace. > > + > > +Userspace always runs at EL0 and thus this attribute will exclude EL0. > > + > > + > > +exclude_kernel > > +-------------- > > + > > +This attribute excludes the kernel. > > + > > +The kernel runs at EL2 with VHE and EL1 without. Guest kernels always run > > +at EL1. > > + > > +This attribute will exclude EL1 and additionally EL2 on a VHE system. > > I find this last sentence a bit confusing, because it can be read to imply > that if you don't set exclude_kernel and you're in a guest on a VHE system, > then you can profile EL2. Yes this could be misleading. However from the perspective of the guest, when exclude_kernel is not set we do indeed allow the guest to program it's PMU with ARMV8_PMU_INCLUDE_EL2 - and thus the statement above is correct in terms of what the kernel believes it is doing. I think these statements are less confusing if we treat the exception levels as those 'detected' by the running context (e.g. consider the impact of nested virt here) - and we if ignore what the hypervisor (KVM) does outside (e.g. stops counting upon switching between guest/host, translating PMU filters in kvm_pmu_set_counter_event_type etc, etc). This then makes this document useful for those wishing to change this logic (which is the intent) rather than those trying to understand how we filter for EL levels as seen bare-metal. With regards to the example you gave (exclude_kernel, EL2) - yes we want the kernel to believe it can count EL2 - because one day we may want to update KVM to allow the guest to count it's hypervisor overhead (e.g. host kernel time associated with the guest). I could write some preface that describes this outlook. Alternatively I could just spell out what happens on a guest, e.g. "For the host this attribute will exclude EL1 and additionally EL2 on a VHE system. For the guest this attribute will exclude EL1." Though I'm less comfortable with this, as the last statement "For the guest this attribute will exclude EL1." describes the product of both kvm_pmu_set_counter_event_type and armv8pmu_set_event_filter which is confusing to work out and also makes an assumption that we don't have nested virt (true for now at least) and also reasons about bare-metal EL levels which probably aren't that useful for someone changing this logic or understanding what the flags do for there performance analysis. Do you have a preference for how this is improved? > > > +exclude_hv > > +---------- > > + > > +This attribute excludes the hypervisor, we ignore this flag on a VHE system > > +as we consider the host kernel to be the hypervisor. > > Similar comment as the above: I don't think this makes sense when you look > at things from the guest perspective. > > > +On a non-VHE system we consider the hypervisor to be any code that runs at > > +EL2 which is predominantly used for guest/host transitions. > > + > > +This attribute will exclude EL2 on a non-VHE system. > > + > > + > > +exclude_host / exclude_guest > > +---------------------------- > > + > > +This attribute excludes the KVM host. > > But there are two attributes... Oh, I'll have to update this. Thanks for the review, Andrew Murray > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel