Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4005579pxv; Tue, 13 Jul 2021 08:41:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHTbOZXTorNaUXSmGH6Yhpl/MXDcVbqOLxHmeWw7Hs3OXwzDr4sKKtwlDJZ4Phc2o25Tqw X-Received: by 2002:a5d:9499:: with SMTP id v25mr3568863ioj.137.1626190892982; Tue, 13 Jul 2021 08:41:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626190892; cv=none; d=google.com; s=arc-20160816; b=na/x7dPDNxVlVrmluyR9m6oy6b/qclgqY2mrdCLCFYk+174mo02e8DkXhc7y2RouuZ d9ERGMPb3JK6owswByjnptNjIiuH2dvdgq5oyZ3dXHYvM2hI0vLN+uzQpHlrWAuynM1t lea68czwa/EzNTYMQqyXAvQUhhzhd2rl7mcNNq7Ua0ohdm0t5Do9Rvwp/g35i28pjffH wvIV0uLo3fIK61TOUohi1tDxXNZv5c17Sc6n3RmSy2HyMe/B52GIucWWw046hNZbQRD0 llxsJSxulTJxa4gBAtzNo3lsobNXQsU//RNee0h8BTqKuLJNisV/7XC+FmIblz0DRAUo 8oig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=jxKvtCbJ/r1EoUdG+f37+hha5Wa+VvpwXrpbZ+sJ+HQ=; b=rNELprhMZ/fKb4cyeo/T6tLeOE8CBs8amcUQEQVMOzxrdi5QmzsSpoTNv56l1PUy11 pd/j2/AqMnxiVdrPNSyQ7kpXFkjP2N0ue+Qi+XsISxfvVLl8nUF+gvUBiTXw8IngkrAp QVmDZJtDbuWLKMhBVE8aPZiyTwS1Ffe4GXSc9QcdCjZR+7t8JpsnD/G8x/0sHcv7askM itgoxBXXeQ9s8cy8wwW1MlSgINGJZNpDcda4pbxVllm5SWMzEtpPENxIfc7SEpSgHuqt d1QZ4oPY/uvvRBPS89kJ8NbKhm9YoL0jpH0A8jwUeQTuAs8Y3dikbCeD/zLYXDuhhT9E a6/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t8si7587214ils.46.2021.07.13.08.41.20; Tue, 13 Jul 2021 08:41:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S237148AbhGMPn2 (ORCPT + 99 others); Tue, 13 Jul 2021 11:43:28 -0400 Received: from foss.arm.com ([217.140.110.172]:45554 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236932AbhGMPn2 (ORCPT ); Tue, 13 Jul 2021 11:43:28 -0400 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 2B6A1D6E; Tue, 13 Jul 2021 08:40:38 -0700 (PDT) Received: from e121896.arm.com (unknown [10.57.35.35]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 06BAE3F774; Tue, 13 Jul 2021 08:40:33 -0700 (PDT) From: James Clark To: acme@kernel.org, mathieu.poirier@linaro.org, coresight@lists.linaro.org, leo.yan@linaro.org Cc: al.grant@arm.com, branislav.rankov@arm.com, suzuki.poulose@arm.com, anshuman.khandual@arm.com, James Clark , Mike Leach , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , John Garry , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/6] perf cs-etm: Refactor initialisation of kernel start address Date: Tue, 13 Jul 2021 16:40:03 +0100 Message-Id: <20210713154008.29656-2-james.clark@arm.com> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20210713154008.29656-1-james.clark@arm.com> References: <20210713154008.29656-1-james.clark@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The kernel start address is already cached in the machine struct once it is initialised, so storing it in the cs_etm struct is unnecessary. It also depends on kernel maps being available to be initialised. Therefore cs_etm__setup_queues() isn't an appropriate place to call it because it could be called before processing starts. It would be better to initialise it at the point when it is needed, then we can be sure that all the necessary maps are available. Also by calling machine__kernel_start() multiple times it can be initialised at some point, even if it failed to initialise previously due to missing maps. In a later commit cs_etm__setup_queues() will be moved which is the motivation for this change. Signed-off-by: James Clark --- tools/perf/util/cs-etm.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index bc1f64873c8f..4c69ef391f60 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -62,7 +62,6 @@ struct cs_etm_auxtrace { u64 instructions_sample_period; u64 instructions_id; u64 **metadata; - u64 kernel_start; unsigned int pmu_type; }; @@ -691,7 +690,7 @@ static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address) machine = etmq->etm->machine; - if (address >= etmq->etm->kernel_start) { + if (address >= machine__kernel_start(machine)) { if (machine__is_host(machine)) return PERF_RECORD_MISC_KERNEL; else @@ -901,9 +900,6 @@ static int cs_etm__setup_queues(struct cs_etm_auxtrace *etm) unsigned int i; int ret; - if (!etm->kernel_start) - etm->kernel_start = machine__kernel_start(etm->machine); - for (i = 0; i < etm->queues.nr_queues; i++) { ret = cs_etm__setup_queue(etm, &etm->queues.queue_array[i], i); if (ret) -- 2.28.0