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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 2973DC2BA18 for ; Thu, 20 Jun 2024 04:22:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=McVfcAWLvqIGry5wawttglU1fSKtrSV4mjU/uo0+/Z8=; b=BczO3gw8bzF8XMPYyo7PxV9aUO ywHilh2ZrRwex72IY1gipysq2BeSfScKlIIJoPodlM+VOZEdE0v5GZauCYN8uwzCJVARMKBgWoncc gLfe6xKZ+YgUnuAXJwIax8gAeg8FgpiUQ3TbNpOpGFy7cAhEf2ql94sfVAfzh7H82uNRLBPIajnud Tfz2GhDsUzKfOuGsDrWfqkrebFcbiCzakMGmIfuD7yIVhtUJedejZzd2N3esIh0HSaf4R3gN/AjzP IDkcqu052Cl5OPpmIuFVKcsTl2oesi6L+yRsv2gP01vdGEFPkdUUwNhybopFswalhrT54wLdo+vTA o5tV5tfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sK9JT-00000003ZAV-1MRz; Thu, 20 Jun 2024 04:22:19 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sK9JQ-00000003Z9g-2Bcd for linux-arm-kernel@lists.infradead.org; Thu, 20 Jun 2024 04:22:18 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6AFB6DA7; Wed, 19 Jun 2024 21:22:39 -0700 (PDT) Received: from [10.163.46.59] (unknown [10.163.46.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B3D13F64C; Wed, 19 Jun 2024 21:22:08 -0700 (PDT) Message-ID: Date: Thu, 20 Jun 2024 09:52:05 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V18 6/9] KVM: arm64: nvhe: Disable branch generation in nVHE guests Content-Language: en-US To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, Mark Brown , James Clark , Rob Herring , Marc Zyngier , Suzuki Poulose , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , linux-perf-users@vger.kernel.org, Oliver Upton , James Morse , kvmarm@lists.linux.dev References: <20240613061731.3109448-1-anshuman.khandual@arm.com> <20240613061731.3109448-7-anshuman.khandual@arm.com> <774a63cb-21e6-4ef2-b2ab-0ff8937523b2@arm.com> From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240619_212216_683029_237B3DC8 X-CRM114-Status: GOOD ( 25.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 6/17/24 15:09, Mark Rutland wrote: > On Mon, Jun 17, 2024 at 12:15:15PM +0530, Anshuman Khandual wrote: >> >> >> On 6/14/24 20:53, Mark Rutland wrote: >>> On Thu, Jun 13, 2024 at 11:47:28AM +0530, Anshuman Khandual wrote: >>>> Disable the BRBE before we enter the guest, saving the status and enable it >>>> back once we get out of the guest. This avoids capturing branch records in >>>> the guest kernel or userspace, which would be confusing the host samples. >>> >>> It'd be good to explain why we need to do this for nVHE, but not for >>> VHE. I *think* that you're relying on BRBCR_EL2.EL0HBRE being ignored >>> when HCR_EL2.TGE == 0, and BRBCR_EL1.E{1,0}BRE being initialized to 0 >>> out-of-reset. >> >> That's right, there is no possibility for the host and guest BRBE config >> to overlap. >> >>> What should a user do if they *want* samples from a guest? Is that >> >> That is not supported currently. But in order to enable capturing guest >> branch samples from inside the host - BRBCR_EL2 configs need to migrate >> into BRBCR_EL1 when the guest runs on the cpu. >> >>> possible to do on other architectures, or do is that always prevented? >> >> I am not sure about other architectures, but for now this falls within >> guest support which might be looked into later. But is not the proposed >> patch complete in itself without any further guest support ? > > My concern here is ABI rather than actual support. I am trying to understand how this is an ABI problem. Because perf debug tools could be described as - a best effort based sample collection. All samples that could be collected for a given perf_event_attr request might change if the underlying assumptions change later on. AFAICT semantics of expectations for a given attribute request is not a hard ABI requirement. > > It's not clear to me how this works across architectures, and we should > have some idea of how this would work (e.g. if we're going to require > new ABI or not), so that we don't have to break ABI later on. BRBE HW does not have any guest filter in itself, unless BRBCR_EL2 gets migrated across BRBCR_EL1 during guest transition, guest branch records would not be captured. event->attr.exclude_guest = 0 could have been denied during armpmu_add() for preventing events with guest branch sample requests being scheduled on the PMU. But it turns out to be not a very reliable parameter in that sense as well. event->attr.exclude_guest = 0 remains clear even for a standard session. ./perf record -e instructions:k -j any_call,save_type ls perf tools will need some changes in order to avoid the above scenarios as a default behaviour which would not be desirable as well. These semantics could be worked out later on when BRBE guest support gets included, and the current proposal would not prevent any potential future changes in this regard. > > Mark.