Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3562508ybt; Tue, 23 Jun 2020 05:34:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbcyHkyXDThKeiiLLey5zQ9KizFuEE6Qd5JrSCE5SXASgLgN66oI8CKHEsnhpcGDZ2Y8PR X-Received: by 2002:aa7:c157:: with SMTP id r23mr22031291edp.139.1592915679027; Tue, 23 Jun 2020 05:34:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592915679; cv=none; d=google.com; s=arc-20160816; b=qCqa4AYZzBhDo+kTSvAiTFSE2iIv5pktjxCRW+yedlvUJwS+A1QmJ6x9oOGj2TBeWP cqt4dh3b4ZQOmZL5iqQITHgjzDuqDuKqGUoX3FpuLosWUYKJ12nlTuhhfpbENV4A9EjH o4PtPhwKoMQ7+pA5swOS+ks1iPfKBfDTW/GyRwdeYx/54o8dKCU4WY45i6FBRPGjxu09 olE+EO2Y8+M7ZnLCIGIWjdh7rc/YVnDxCF4oYdp/57C9ixaRovk+1/9o3zQ+H9l5cW8+ htGaDI2YhduXEjWa80i+BV0HzRj2wVAX9vHv75Fx0maM0gDbM/cVavJvrunX7Xxuhoxa C02w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=qV7XAUgsCuLF6+WpAqvX6SABYvM7I3wDpYee98VvLBE=; b=GsLLWaftyeIKKWpuDSiHx33mxuB/YhB41VbSJnywbazDthRBtd6a+keAwcoZ0dU+S3 jyzRL9pXezZdzhneqXKkODgMRQyVg5e2Fm6CYfaX9S+l7vB0oDG2nYsKPSIqpNbdVZ5p Z913ltRjk+EjFp7+BBZ8rJOsz0bdoDofHbypvCP1TJULLwqfsrIF3Yfi+zWeVDpNoUbU P3ZXbQb8I3UNdW4rZ+4lq/Z1ssITu9ByRbWTHHpc5PkYaZiQ6OLqq9iJyvpP40eVzSgo XOxGO5c8Fqtrm4h6D5cxXOljtS9GlLwq8tG0u5ebkCGQ3TtV6AWVR/aphQ8dBDHfyCzx JcAg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n25si11389669ejs.551.2020.06.23.05.34.15; Tue, 23 Jun 2020 05:34:39 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732608AbgFWMcF (ORCPT + 99 others); Tue, 23 Jun 2020 08:32:05 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:6823 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732566AbgFWMcD (ORCPT ); Tue, 23 Jun 2020 08:32:03 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 3FA7A6E18D86B20D8779; Tue, 23 Jun 2020 20:32:02 +0800 (CST) Received: from euler.huawei.com (10.175.124.27) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.487.0; Tue, 23 Jun 2020 20:32:01 +0800 From: Wei Li To: Mathieu Poirier , Suzuki K Poulose , Mike Leach , "Arnaldo Carvalho de Melo" , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Kim Phillips CC: , , Peter Zijlstra , Ingo Molnar Subject: [PATCH 2/2] perf tools: Fix record failure when mixed with ARM SPE event Date: Tue, 23 Jun 2020 20:31:41 +0800 Message-ID: <20200623123141.27747-3-liwei391@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200623123141.27747-1-liwei391@huawei.com> References: <20200623123141.27747-1-liwei391@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.124.27] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When recording with cache-misses and arm_spe_x event, i found that it will just fail without showing any error info if i put cache-misses after arm_spe_x event. [root@localhost 0620]# perf record -e cache-misses -e \ arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,load_filter=1,\ jitter=1,store_filter=1,min_latency=0/ sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.067 MB perf.data ] [root@localhost 0620]# perf record -e \ arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,load_filter=1,jitter=1,\ store_filter=1,min_latency=0/ -e cache-misses sleep 1 [root@localhost 0620]# Finally, i found the reason is that the parameter 'arm_spe_pmu' passed to arm_spe_recording_init() in auxtrace_record__init() is wrong. When the arm_spe_x event is not the last event, 'arm_spe_pmus[i]' will be out of bounds. It seems that the code can't support concurrent multiple different arm_spe_x events currently. So add the code to check and record the found 'arm_spe_pmu' to fix this issue. In fact, we don't support concurrent multiple same arm_spe_x events either, that is checked in arm_spe_recording_options(), and it will show the relevant info. Fixes: ffd3d18c20b8d ("perf tools: Add ARM Statistical Profiling Extensions (SPE) support") Signed-off-by: Wei Li --- tools/perf/arch/arm/util/auxtrace.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/tools/perf/arch/arm/util/auxtrace.c b/tools/perf/arch/arm/util/auxtrace.c index 62b7b03d691a..7bb6f29e766c 100644 --- a/tools/perf/arch/arm/util/auxtrace.c +++ b/tools/perf/arch/arm/util/auxtrace.c @@ -58,6 +58,7 @@ struct auxtrace_record bool found_etm = false; bool found_spe = false; static struct perf_pmu **arm_spe_pmus; + static struct perf_pmu *arm_spe_pmu; static int nr_spes = 0; int i = 0; @@ -77,6 +78,13 @@ struct auxtrace_record for (i = 0; i < nr_spes; i++) { if (evsel->core.attr.type == arm_spe_pmus[i]->type) { + if (found_spe && (arm_spe_pmu != arm_spe_pmus[i])) { + pr_err("Concurrent multiple SPE operation not currently supported\n"); + *err = -EOPNOTSUPP; + return NULL; + } + + arm_spe_pmu = arm_spe_pmus[i]; found_spe = true; break; } @@ -94,7 +102,7 @@ struct auxtrace_record #if defined(__aarch64__) if (found_spe) - return arm_spe_recording_init(err, arm_spe_pmus[i]); + return arm_spe_recording_init(err, arm_spe_pmu); #endif /* -- 2.17.1