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 267ACCD37B4 for ; Wed, 4 Sep 2024 12:37:07 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ZJAKNPsqiYzbrQlYr1ABCd9UMJ83Gyo6KvFbcOCAMFM=; b=GOkjA6YBvB364JUgYp+TqYRoyL 1SoJ5qtxapbQek4sTS7D3CPtQhZTTl05EUvzCHJgkVhLFPklHY1x5/dQ1QAAdOHPrVLpi9y68dK02 l+pNPZ+y+zCh+qw0aUUtJBaqbGTxguVZwvDtdfw8alHuDcjg8krWnpZFldoOwbOA1gAc6/ln/n8mf zVxQ3dsyMcGzjaQ3rX+7jPjvtGHvhobEM6S1f7Kn4jANJEk5muPccFmwb+WEdN50kWgvJQeqB1JdY g/1qO1Z7QNd67h3WXiyI4gV7CoJS0Ec6qHKIT6Xk6isqyNWSIewBnwO9m/NOhpwhKD7h7fvqqMbKY 93EBR6bQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1slpFq-00000004O2Z-1ISI; Wed, 04 Sep 2024 12:36:58 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1slpEv-00000004Nwx-0ZNQ for linux-arm-kernel@bombadil.infradead.org; Wed, 04 Sep 2024 12:36:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ZJAKNPsqiYzbrQlYr1ABCd9UMJ83Gyo6KvFbcOCAMFM=; b=DmR8f7ER6ys0xG1jnlLECT879G gvrjFza1ZuPbk0mJx7nZuuA8at0AmekN8b6DHHomIMVj0kWbpyaMg4J8HVF9UuLCA8VIWgFIdnGvw 7TPspKCsjKfZR9qoZJeRsd8t0GO1dRwtgsUhvgoLH0Ew7hXp3N30h6+A5m3p1t7tlhnG7POHPOag+ hKLHNQ0pK+hhv2Pz1Du2TNrJCYthpAvZQ7qtS26PMwfLXmvu3AzQOH8g5jJ1U3Ghp/9qqP4JSRWwV 2LDmX+ytyPU8g8O+raxXMWUcwNGoPYDHpBlDznitoKiqLkKQMcobOe9aRwMyCrP5UNpChmyfTEJnz h4+eJ8lQ==; Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by desiato.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1slpEr-00000000Ctj-1FQ9 for linux-arm-kernel@lists.infradead.org; Wed, 04 Sep 2024 12:35:59 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id ADD70A44283; Wed, 4 Sep 2024 12:35:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0932C4CEC6; Wed, 4 Sep 2024 12:35:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725453353; bh=fjWW4m3Ll2ydWjHg6gzxX2V7+q9bKZYwiViXSnn/3Ac=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CpkgEkRc+CChmGCkYFkh1y56Dld92UgaWYbJ00E28R0XnsGC6NyORq5U+a7/eMjQe 3K3r28UGRqlCK+gz2JyR3QPSRmtP8NpcRxUfI84sRUXtaqvoxniVdZmaC22ovYWAGv qWWTvYs2OF8nb+CuvzKIo4ZR+oVeMrukJ3vffBJT9VCCtbqkpngIu7OfEy/tmJa8sc WiccfciL75imt4RyDkcMJnOt0Pfns6YQP0+p6KWydop0JcmqnydRz4zyrNXlvohDY4 Foge2izuF1WNAy4zGcOURTQXJvWxTYTZvTJWaq8Qqo0NYtvxL9lJkbEZsBq6O1CzEq u6WrZ6mafocOQ== Date: Wed, 4 Sep 2024 13:35:47 +0100 From: Will Deacon To: Leo Yan 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 Subject: Re: [PATCH v1 1/9] perf: arm_spe: Introduce 'lds' capacity Message-ID: <20240904123544.GG13550@willie-the-truck> 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> <0c6d3625-228a-4cb0-b75f-57f1d4069ced@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c6d3625-228a-4cb0-b75f-57f1d4069ced@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240904_133557_765995_F3FDA9F6 X-CRM114-Status: GOOD ( 32.78 ) 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 Sat, Aug 31, 2024 at 12:37:29PM +0100, Leo Yan wrote: > 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. I don't think we shyould expose UAPI from the driver to detect potential hardware bugs. Let's add it when we know it's useful for something instead. > > >> 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. What exactly do you mean by this? As far as I can tell: - Data source packets are either present or absent depending on LDS - You need CPU-specific information to decode them it they are present So it's neither necessary nor sufficient to expose the LDS bit to userspace. Will