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 02189CA101C for ; Sat, 31 Aug 2024 11:38:49 +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=zii+3dytPDMxckTNV96S2O3fJ8nNrLxtmpK9ty8kVEU=; b=QAGQUhxiiLd0Q3fX4yq5g8yDnX tvC99BYiSFyjPLagcFIw7btEiDjAlz8PjqyNM/bWCUB1KupXb0M/Nhn0GZxPUjsv8FFTalw2csKd7 sKyjZVuykyA+LE908rMEL5EojJeqHukSyV/LDki9eFAG63Os9Oa4G54ccxLg5hMTJ+O1IZvHaCYjw +swNxDCvZrgjoQkDb4aZDd/fh32SWED57HI7i4q//oiQtZitQiHe7GUSqUesbo8fKjYza/Yf145uq TO0Sezp+GJlcErN82Jmk1q0UU9tScNYUqooTVpkwuvcq2p24xXJzf9GY4QmVaMf/JjhjDs6Tb2QA+ gnHD9RKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1skMRD-00000009GAy-35yY; Sat, 31 Aug 2024 11:38:39 +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 1skMQK-00000009G7H-0AXB for linux-arm-kernel@lists.infradead.org; Sat, 31 Aug 2024 11:37:45 +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 B463D339; Sat, 31 Aug 2024 04:38:05 -0700 (PDT) Received: from [10.57.87.50] (unknown [10.57.87.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D119F3F762; Sat, 31 Aug 2024 04:37:36 -0700 (PDT) Message-ID: <0c6d3625-228a-4cb0-b75f-57f1d4069ced@arm.com> Date: Sat, 31 Aug 2024 12:37:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/9] perf: arm_spe: Introduce 'lds' capacity To: Will Deacon Cc: Arnaldo Carvalho de Melo , Mark Rutland , Suzuki K Poulose , Mike Leach , James Clark , John Garry , Namhyung Kim , Ian Rogers , Adrian Hunter , "Liang, Kan" , Jonathan Cameron , Yicong Yang , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, coresight@lists.linaro.org, linux-perf-users@vger.kernel.org References: <20240827164417.3309560-1-leo.yan@arm.com> <20240827164417.3309560-2-leo.yan@arm.com> <20240830103834.GA8000@willie-the-truck> <655edf2e-8e0d-4c00-91a1-1af58593f597@arm.com> <20240830130930.GA8615@willie-the-truck> Content-Language: en-US From: Leo Yan In-Reply-To: <20240830130930.GA8615@willie-the-truck> 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-20240831_043744_204125_DAEAE5BB X-CRM114-Status: GOOD ( 21.61 ) 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 8/30/2024 2:09 PM, Will Deacon wrote: [...] >>>> @@ -160,6 +162,7 @@ static ssize_t arm_spe_pmu_cap_show(struct device *dev, >>>> >>>> static struct attribute *arm_spe_pmu_cap_attr[] = { >>>> SPE_CAP_EXT_ATTR_ENTRY(arch_inst, SPE_PMU_CAP_ARCH_INST), >>>> + SPE_CAP_EXT_ATTR_ENTRY(lds, SPE_PMU_CAP_LDS), >>>> SPE_CAP_EXT_ATTR_ENTRY(ernd, SPE_PMU_CAP_ERND), >>>> SPE_CAP_EXT_ATTR_ENTRY(count_size, SPE_PMU_CAP_CNT_SZ), >>>> SPE_CAP_EXT_ATTR_ENTRY(min_interval, SPE_PMU_CAP_MIN_IVAL), >>> >>> What will userspace do with this? I don't think you can turn LDS on/off, >>> so either you'll get the data source packet or you won't. >> >> Yes, LDS bit does not work as a switch. >> >> The tool in the userspace will record the LDS bit into the metadata. During >> decoding phase, it reads out the LDS from metadata. Based on it, the perf >> tool can know if the data source is supported or not, if yes then decode the >> data source packet. > > Why not just decode a data source packet when you see it? i.e. assume LDS > is always set. The current tool works this way to directly decode a data source packet. However, as Arm ARM section D17.2.4 "Data Source packet" describes, the loaded data source is implementation dependent, the data source payload format also is implementation defined. We are halfway here in using the LDS bit to determine if the data source is implemented. However, we lack information on the data source format implementation. As a first step, we can use the LDS bit for sanity checking in the tool to detect any potential silicon implementation issues. Once we have an architectural definition for the data source format, we can extend the tool accordingly. >> Another point is how to decide the data source packet format. Now we maintain >> a CPU list for tracking CPU variants which support data source trace. For long >> term, I would like the tool can based on hardware feature (e.g. a ID register >> in Arm SPE) to decide the data source format, so far it is absent. This is why >> LDS bit + CPU list is a more reliable way. See some discussion [1]. > > Huh. Why would you have a CPU in the list if it _doesn't_ have LDS? Yeah, this is what we don't expect - we can verify the implementation based on LDS bit. E.g. if users ask data source related questions, we can use LDS bit (saved in the perf metadata) to confirm the feature has been implemented in a silicon. > If we have to resort to per-CPU decoding, then that's even more of a reason> not to have the LDS cap imo. This series converts the Arm SPE information into per-CPU metadata, including the LDS bit. Consequently, the decoding process retrieves CPU metadata for per-CPU decoding, making it easy to determine if a CPU supports the data source. We have platforms that not all CPUs support Arm SPE, for example, the CPU0 and CPU1 don't support Arm SPE, CPU2~CPU5 share a Arm SPE PMU event, CPU6~CPU7 share another Arm SPE PMU event. In this case, per CPU metadata can be easily for checking hardware capacity (include LDS bit) in the decoding. Thanks, Leo