Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp4379906rwo; Tue, 25 Jul 2023 05:24:52 -0700 (PDT) X-Google-Smtp-Source: APBJJlG9ISaqFK6SaWU6zpA9a6N2Ux1euIcXlkLALI0Y7+6e1u6UuWTOf258pIqyt20VzGu+wn2k X-Received: by 2002:a05:6358:8812:b0:134:c1eb:8744 with SMTP id hv18-20020a056358881200b00134c1eb8744mr7056744rwb.9.1690287892066; Tue, 25 Jul 2023 05:24:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690287892; cv=none; d=google.com; s=arc-20160816; b=nUgNylcUSgIZvZFaq44599Te+tOdtJLFP1NwIpNCh1mRQ8K7QNuvGIfaxg6SPrUI+p 94EoZJNLrNyuCyDH+oaMUaFIIfP5GXXk3arXGX4ZtgasgrYx/JnOY7D4PyjVKoqiltJ0 kduQLcHBfJEr1zBLBxLwF3y7hvd1UFesjdwH7dNfVaUSrLIL27ClN05x/CM0eSyUDwO4 /dOREgktxYsFnm4s22fafQr8Frv9gcElNLGPynj+0LpYZiHIdqpDqaTs5qf/yzOtJQxf gg+t5QqfaVAJLqEw7VcT/s4BrBvRB6xwfGT8Pvu77jRSry3+iCKXOe8LlXYXJ9d4+8lz GS3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=cnglWBnnW81RXmgNJ9fesRY8yd6HRhHfMO5hf5PFilc=; fh=YKMqgIC6Q9CplCGL1krIAOGTGEJnsNx/u1ihvVhih7I=; b=pZ0SSwd5jlsPN3+uzdHPKuTRPz3FAMOOtCkafefCnAl4Mcx+zFuQkVnBI6vSX2OyYp ez5xR2/X/5676I18pLVOH7UN8VtlME4q7DDIVDwYD3Z1+p6uC16dVtr/OaGRgY++57KJ T2FmQ1kaqccEwtnmGobzxwWl+IRaKx2RSIiM003P3XbvqYYcIjFffufrX424vJyGJxVu 2UXvSgq1rGbegU0n2R2ZoJGBZep0H4xQPHtuCJW6J4yjdWS8tni64OoqcuWtf/TB5JAh BdF4TzlELwUSKlMtIfe2s5Ipb+LFZcywD9/r3Rrmy6eFbJgysP3ZAqxA1ity7R1E4jW2 /ibg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x185-20020a6386c2000000b00563d478ce7fsi422003pgd.746.2023.07.25.05.24.38; Tue, 25 Jul 2023 05:24:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235013AbjGYLnp (ORCPT + 99 others); Tue, 25 Jul 2023 07:43:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235455AbjGYLnf (ORCPT ); Tue, 25 Jul 2023 07:43:35 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6D367212D; Tue, 25 Jul 2023 04:43:22 -0700 (PDT) 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 B62BE15BF; Tue, 25 Jul 2023 04:43:30 -0700 (PDT) Received: from [10.163.51.115] (unknown [10.163.51.115]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C5AEB3F67D; Tue, 25 Jul 2023 04:42:42 -0700 (PDT) Message-ID: <9d07e82a-06fb-a5f8-6f4f-f3c16784b9b7@arm.com> Date: Tue, 25 Jul 2023 17:12:40 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH V13 - RESEND 06/10] arm64/perf: Enable branch stack events via FEAT_BRBE Content-Language: en-US To: Yang Shen , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com Cc: Mark Brown , James Clark , Rob Herring , Marc Zyngier , Suzuki Poulose , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , linux-perf-users@vger.kernel.org References: <20230711082455.215983-1-anshuman.khandual@arm.com> <20230711082455.215983-7-anshuman.khandual@arm.com> <5c7c1ff3-1e2a-1258-7fa0-c82a9ab62646@huawei.com> From: Anshuman Khandual In-Reply-To: <5c7c1ff3-1e2a-1258-7fa0-c82a9ab62646@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Yang, On 7/25/23 12:42, Yang Shen wrote: >> +    if (!(branch_type & PERF_SAMPLE_BRANCH_NO_CYCLES)) >> +        brbcr |= BRBCR_EL1_CC; > > Hi Anshuman, > > Here is problem about enable CYCLES_COUNT. The SPEC defines that the CYCLES_COUNT is only > > valid when the BRECR_EL1.CC & BRBCR_EL2.CC is true. And here the SPEC also defines that > > when PSTATE.EL == EL2 and HCR_EL2.E2h == '1', 'MSR BRBCR_EL1, ' means writing to > > BRBCR_EL2 actually. So 'armv8pmu_branch_enable' can only set the BRBCR_EL2.CC, while the > > BRECR_EL1.CC is still 0. The CYCLES_COUNT will be always 0 in records. Agreed, this is a valid problem i.e BRBCR_EL1.CC and BRBCR_EL2.CC both needs to be set for valid cycle count information regardless if the kernel runs in EL1 or EL2. A simple hack in the current code setting BRBCR_EL12.C, which in turn sets BRBCR_EL1.CC when the kernel runs in EL2 solves the problem. > > As a solution, maybe BRBCR_EL12 should be added for driver according to the registers definition. Right, will add the definition for BRBCR_EL12 in arch/arm64/tools/sysreg > > Or, do you have a more standard solution? Right, there are some nuances involved here. Kernel could boot a. Directly into EL2 and stays in EL2 for good b. Directly into EL2 but switches into EL1 c. Directly into EL1 without ever going into EL2 In all the above cases BRBCR_EL1.CC and BRBCR_EL2.CC needs to be set when cycle count is requested in the perf event interface (event->attr.branch_sample_type) via clearing PERF_SAMPLE_BRANCH_NO_CYCLES. - For the case as in (c) where kernel boots into EL1 directly and hence cannot ever set EL2 register, BRBCR_EL2.CC would be a booting requirement - updated in booting.rst - For the cases as in (a) and (b) kernel boots via EL2, hence there is an opportunity to set both BRBCR_EL1.CC (via accessed BRBCR_EL12.CC) and BRBCR_EL2.CC. Depending on where the kernel lands up eventually, either BRBCR_EL1.CC or BRBCR_EL2.CC will be the toggle switch to ON or OFF cycle counting in the driver via branch_type_to_brbcr(). So a new macro __init_el2_brbe is required which will get called from init_el2_state setting both the register fields as explained earlier. I am working on these changes, will post the code soon.