Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1033066iob; Wed, 4 May 2022 13:09:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxWl/AbaqeXZZzxHS36JiEvMoHRzIpdPvQuEPMnY+Gx7zle5rKZ0UHlDI+hGaBOfhnMytjs X-Received: by 2002:a17:902:f608:b0:158:29e6:c88 with SMTP id n8-20020a170902f60800b0015829e60c88mr22973799plg.174.1651694964871; Wed, 04 May 2022 13:09:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651694964; cv=none; d=google.com; s=arc-20160816; b=tYtzKe8cwO0olzFtGCAaWNGceQCdQG0SOiLQ2ctO+O2KbnGOQJLjDqnKiF9XIqn69q mrzjAoU/uenB0SMlrf+bpVRnYhUWQcOQKwv7hMaWBGtWLG1ILT8aQNP1Pj6TEGZauKPF RQepjbsNbY0H9KRF9qLoXY2+QslxtP4KiqYCT+YrRNrpvPWyMOEGU7C/TyOn/yxjf4MC 4lEa2+fdJyTGkoalbJDi1imXad0qrzGdGLsPiIuP0Um0nZGrqt/m9+d7a5m9kmtYv5fk Mmyvgt9OG/r4q8UKOAsqy1JLRBnuh9yLc/eQCmJtY9yEutozJSohlwkaGuGu67/JOq4f nK/Q== 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:subject:user-agent:mime-version:date:message-id; bh=i+l0oLY0/uManbKcXRKc/WGB7Tpmtc6Q2KtKFknF10Y=; b=bj8uO743pyxdPSiVvXapTW8DXL+6WT1dKoE6HS5h5a1DhJ/b3HmcS6e1Gq0MoSsRUx VslD2UiA5uxjb1QTtsQObASpe28eYmS5wyGzwcJzbMqbAE5jCl+J1QxgUkeuw2CLSEq4 kPtDbg7ugeshfWoltmNx/x52SJXLw0byTHSnOUDEr+cbWocY27H4rY2khvgqDJk5poL4 1kYIXHvUd3qBFcVg8D99OJUKXsvn3OfMcKHGaVIhwB2LuIWghRY1/2/I+wepuLRtplMn 8w3F9rvgx+bUahASx8iLPv8rsWTSvJ9YwOu72AR/N65MK9iLpP/xyDVYrIJ/H2J4eh0w 74bg== 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 l19-20020a635b53000000b003aaa481915asi19783600pgm.864.2022.05.04.13.09.07; Wed, 04 May 2022 13:09:24 -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 S1347711AbiEDJuC (ORCPT + 99 others); Wed, 4 May 2022 05:50:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346296AbiEDJuA (ORCPT ); Wed, 4 May 2022 05:50:00 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C2BC81D0F0; Wed, 4 May 2022 02:46:24 -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 9070FED1; Wed, 4 May 2022 02:46:24 -0700 (PDT) Received: from [10.57.1.74] (unknown [10.57.1.74]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6D1D03FA50; Wed, 4 May 2022 02:46:22 -0700 (PDT) Message-ID: Date: Wed, 4 May 2022 10:46:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v2 1/6] coresight: Add config flag to enable branch broadcast To: James Clark , Mike Leach Cc: coresight@lists.linaro.org, leo.yan@linaro.com, John Garry , Will Deacon , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org References: <20220113091056.1297982-1-james.clark@arm.com> <20220113091056.1297982-2-james.clark@arm.com> <7fae6630-fdec-3f95-9eac-3f7a5c789272@arm.com> From: Suzuki K Poulose In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,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 On 22/04/2022 11:18, James Clark wrote: > > > On 11/03/2022 15:56, Mike Leach wrote: >> Hi James, >> >> On Fri, 11 Mar 2022 at 14:58, James Clark wrote: >>> >>> >>> >>> On 02/02/2022 20:25, Mike Leach wrote: >>>> Hi James, Suzuki >>>> >>>> On Fri, 28 Jan 2022 at 11:19, Suzuki K Poulose wrote: >>>>> >>>>> On 13/01/2022 09:10, James Clark wrote: >>>>>> When enabled, all taken branch addresses are output, even if the branch >>>>>> was because of a direct branch instruction. This enables reconstruction >>>>>> of the program flow without having access to the memory image of the >>>>>> code being executed. >>>>>> >>>>>> Use bit 8 for the config option which would be the correct bit for >>>>>> programming ETMv3. Although branch broadcast can't be enabled on ETMv3 >>>>>> because it's not in the define ETM3X_SUPPORTED_OPTIONS, using the >>>>>> correct bit might help prevent future collisions or allow it to be >>>>>> enabled if needed. >>>>>> >>>>>> Signed-off-by: James Clark >>>>>> --- >>>>>> drivers/hwtracing/coresight/coresight-etm-perf.c | 2 ++ >>>>>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++ >>>>>> include/linux/coresight-pmu.h | 2 ++ >>>>>> 3 files changed, 14 insertions(+) >>>>>> >>>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c >>>>>> index c039b6ae206f..43bbd5dc3d3b 100644 >>>>>> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c >>>>>> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c >>>>>> @@ -52,6 +52,7 @@ static DEFINE_PER_CPU(struct coresight_device *, csdev_src); >>>>>> * The PMU formats were orignally for ETMv3.5/PTM's ETMCR 'config'; >>>>>> * now take them as general formats and apply on all ETMs. >>>>>> */ >>>>>> +PMU_FORMAT_ATTR(branch_broadcast, "config:"__stringify(ETM_OPT_BRANCH_BROADCAST)); >>>>>> PMU_FORMAT_ATTR(cycacc, "config:" __stringify(ETM_OPT_CYCACC)); >>>>>> /* contextid1 enables tracing CONTEXTIDR_EL1 for ETMv4 */ >>>>>> PMU_FORMAT_ATTR(contextid1, "config:" __stringify(ETM_OPT_CTXTID)); >>>>>> @@ -97,6 +98,7 @@ static struct attribute *etm_config_formats_attr[] = { >>>>>> &format_attr_sinkid.attr, >>>>>> &format_attr_preset.attr, >>>>>> &format_attr_configid.attr, >>>>>> + &format_attr_branch_broadcast.attr, >>>>> >>>>> Does it make sense to hide the option if the bb is not supported ? I >>>>> guess it will be tricky as we don't track the common feature set. So, >>>>> that said...>>>> >>>>>> NULL, >>>>>> }; >>>>>> >>>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>>> index bf18128cf5de..04669ecc0efa 100644 >>>>>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>>> @@ -692,6 +692,16 @@ static int etm4_parse_event_config(struct coresight_device *csdev, >>>>>> ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset); >>>>>> } >>>>>> >>>>>> + /* branch broadcast - enable if selected and supported */ >>>>>> + if (attr->config & BIT(ETM_OPT_BRANCH_BROADCAST)) { >>>>>> + if (!drvdata->trcbb) { >>>>>> + ret = -EINVAL; >>>>> >>>>> Should we fail here ? We could simply ignore this and generate the trace >>>>> normally. This would work on a big.LITTLE system with one set missing >>>>> the branch broadcast, while the others support. > > Hi Suzuki, > > I think if the user really needs branch broadcast because they've modified their > binaries then they would want feedback that one of the cores doesn't support it. > Otherwise their decode would silently go wrong and they could get stuck. > > Perf already opens an event per core, so it wouldn't be much effort to manually > modify the command line to only select cores where it is supported. > > I think for that scenario the current patch already works that way because the > feature is checked on the active core when the event is enabled? Fair enough. We could let the user pin the perf to the CPUs where this is supported. This information is available to the user via sysfs. So, let us proceed with the changes here. Cheers Suzuki