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 90552CD3431 for ; Wed, 4 Sep 2024 14:03:42 +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=bNzReNF7QcPJIXiZbvZrTeucmDR1rgE8Mbm0wkDjXZI=; b=lYKF/rC+a3juBR+ztuLlD+Ad6Z yJN1AlzqAbu06yXvQUSsonz8Z47soD9C3ZpBD7U5l7LpAZ5CVcKG23LL8nFNsrdt23H157Kosd37u TNF7B6wf6WmUIJpwY8w4PYwJMdBz3eG733mnygcgcol573S9ztDb33Kk1ZtshEt9sOovGDKZexrtS 5RB+Iu89vMfGsJ4nZG/9Q9g9mb/Pgw8zKkJMZ59wO88WbvwrPWE/FJRTF2Y/EIUFDRy6Amz1jActu oByR4kGM38xyyUbZKnYnwymEVRIqD6jEddsgwmPyjPGmeglGas+ISoMp8IcSrMQwgSFHZv6tkn6xh cQ2CenWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1slqbb-00000004gO3-1Fx5; Wed, 04 Sep 2024 14:03:31 +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 1slqad-00000004g9r-2FJI for linux-arm-kernel@lists.infradead.org; Wed, 04 Sep 2024 14:02:33 +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 7A33FFEC; Wed, 4 Sep 2024 07:02:54 -0700 (PDT) Received: from [10.1.33.19] (PF4Q20KV.arm.com [10.1.33.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4CD603F73F; Wed, 4 Sep 2024 07:02:26 -0700 (PDT) Message-ID: Date: Wed, 4 Sep 2024 15:02:19 +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> <0c6d3625-228a-4cb0-b75f-57f1d4069ced@arm.com> <20240904123544.GG13550@willie-the-truck> Content-Language: en-US From: Leo Yan In-Reply-To: <20240904123544.GG13550@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-20240904_070231_712362_32408710 X-CRM114-Status: GOOD ( 23.05 ) 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 9/4/2024 1:35 PM, Will Deacon wrote: >>> 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. I understand your concern. >>>> 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? Sometimes, users might ask if the data source is supported in Arm SPE. With exposing the LDS bit, it would be helpful for us to check if the feature is supported. For example, when a user uses the perf tool to record Arm SPE data, the LDS bit is stored in the perf metadata, and we can check its value during post-analysis. > 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. We can live without exposing LDS bit currently. I will drop this change in next spin. Just head up, later I think we might still need to expose capacity bits (or the PMSIDR_EL1 register) for new features. As you said, we can do it when it is necessary. Thanks for suggestion! Leo