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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 853BBC433FE for ; Fri, 17 Dec 2021 09:41:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234485AbhLQJlA (ORCPT ); Fri, 17 Dec 2021 04:41:00 -0500 Received: from foss.arm.com ([217.140.110.172]:53978 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234472AbhLQJk7 (ORCPT ); Fri, 17 Dec 2021 04:40:59 -0500 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 E33331435; Fri, 17 Dec 2021 01:40:58 -0800 (PST) Received: from [10.57.8.4] (unknown [10.57.8.4]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 08D623F774; Fri, 17 Dec 2021 01:40:56 -0800 (PST) Subject: Re: [PATCH 2/3] coresight: Fail to open with return stacks if they are unavailable To: Mike Leach Cc: Suzuki K Poulose , coresight@lists.linaro.org, Leo Yan , John Garry , Will Deacon , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Mathieu Poirier References: <20211208160907.749482-1-james.clark@arm.com> <20211208160907.749482-2-james.clark@arm.com> <20211210172220.GA1238770@p14s> From: James Clark Message-ID: Date: Fri, 17 Dec 2021 09:40:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/12/2021 09:48, Mike Leach wrote: > Hi James, > > A couple of points - relating mainly to docs: > Hi Mike, Thanks for the feedback. I was in the process of adding some docs and ran into this https://lkml.org/lkml/2021/12/16/1087 so I went to fix that first. Now I will add some more details and resubmit. > 1. Activating branch broadcast overrides any setting of return stack. > As a minimum there needs to be a documentation update to reflect this > -Setting both options is not prohibited in hardware - and in the case > where we can use branch broadcast over a range both are then relevant. > Do you mean that if branch broadcast and return stacks are both requested, but branch broadcast is limited to a range, return stacks will only be available outside that branch broadcast range? But if branch broadcast is enabled for all ranges there will be no return stacks at all? > 2. A documented note to reflect that choosing this option will result > in a significant increase in the amount of trace generated - possible > danger of overflows, or less actual instructions covered. In addition > perhaps documents could reflect the intended use-case for this option, > given the disadvantages. > Will do. > 3. Has this been tested in a situation where it will be of use? > Testing against static code images will show the same decoded trace > output as not using branch broadcast. (although the packet dumps will > show additional output)> > Given a primary use is for situations where code is patched or > dynamically altered at runtime - then this can affect the full decode > output. If the code is being patched to only alter the branch > addresses then decode should work against static images. > If, however, we are tracing code that adds in new branches, on top of > NOPs for example, then the decoding against the original static image > will be wrong, as the image will have the NOPs, rather than the branch > instructions so the apparent location of E atoms will be in a > different position to the actual code. Is there anything in perf that > will ensure that the patched code is presented to the decoder? > > If there are potential decode issues - these too need documenting. > I'm not sure this should be a blocking issue for this set. Branch broadcast could already be enabled by setting the mode via sysfs. And the perf decode part isn't necessarily a step in the workflow, maybe someone wants to gather data for another tool. I will do some testing after this change though, but I imagine we would have had issues reported it it wasn't working already which lowers the priority. James > Other than the documents and testing, I cannot see any issues with > this patch set in terms of setting and enabling the option. > > Regards > > Mike > > > On Fri, 10 Dec 2021 at 17:22, Mathieu Poirier > wrote: >> >> Hi James, >> >> On Thu, Dec 09, 2021 at 11:13:55AM +0000, James Clark wrote: >>> >>> >>> On 09/12/2021 11:00, Suzuki K Poulose wrote: >>>> On 08/12/2021 16:09, James Clark wrote: >>>>> Maintain consistency with the other options by failing to open when they >>>>> aren't supported. For example ETM_OPT_TS, ETM_OPT_CTXTID2 and the newly >>>>> added ETM_OPT_BRANCH_BROADCAST all return with -EINVAL if they are >>>>> requested but not supported by hardware. >>>>> >>>>> The consequence of not doing this is that the user may not be >>>>> aware that they are not enabling the feature as it is silently disabled. >>>>> >>>>> Signed-off-by: James Clark >>>>> --- >>>>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 13 +++++++++---- >>>>> 1 file changed, 9 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>> index d2bafb50c66a..0a9bb943a5e5 100644 >>>>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>> @@ -674,10 +674,15 @@ static int etm4_parse_event_config(struct coresight_device *csdev, >>>>> } >>>>> /* return stack - enable if selected and supported */ >>>>> - if ((attr->config & BIT(ETM_OPT_RETSTK)) && drvdata->retstack) >>>>> - /* bit[12], Return stack enable bit */ >>>>> - config->cfg |= BIT(12); >>>>> - >>>>> + if (attr->config & BIT(ETM_OPT_RETSTK)) { >>>>> + if (!drvdata->retstack) { >>>>> + ret = -EINVAL; >>>>> + goto out; >>>>> + } else { >>>>> + /* bit[12], Return stack enable bit */ >>>>> + config->cfg |= BIT(12); >>>>> + } >>>> >>>> nit: While at this, please could you change the hard coded value >>>> to ETM4_CFG_BIT_RETSTK ? >>>> >>> I started changing them all because I had trouble searching for bits by name but then >>> I thought it would snowball into a bigger change so I undid it. >>> >>> I think I'll just go and do it now if it's an issue here. >> >> I can apply this set right away and you send another patch to fix all hard coded >> bitfields or you can send another revision with all 4 patches included in it >> (bitfields fix plus these 3). Just let me know what you want to do. And next >> time please add a cover letter. >> >> Thanks, >> Mathieu >> >>> >>>> Otherwise, looks good to me >>>> >>>> Suzuki > > > 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 2C292C433FE for ; Fri, 17 Dec 2021 09:43:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=owIWe96tozpfxTOi0sOymebeTTyQAriquUXUh1xaU3Q=; b=4//40tjy1FsZ5NUFEOp8VE/MPk 3BNK/7hqzc0OmJSvxAWOgn5566osU9M4eeDzy8hRY3EMP28e0XaEQlvZ7XmFC8pulfBy9/AJ0BpDp z+junOupFV+yoqqc8ZAU0bDQZIk1zGe9qV0gzgsIjvvt8IpUB5ZC5vvwKEN/QUOFM8D43XJsbfkdG ghSuQ7kJSsD3Al/9nlGvBltgxRMxjaqX4ZqgkqhDsAcj95BY3BpgWzSw3WUCVyjsNcj2WJj2IcfmB ayB6FSZeojvBdX/8hLi8QPGRnwTJ0o8ScYb3Ytsuqcqfzi12PbCl8PWc4NWLGr/HEQwj5iGZiq3KO 5AMHQcaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1my9ki-009G3r-Gi; Fri, 17 Dec 2021 09:42:12 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1my9jZ-009FRh-My for linux-arm-kernel@lists.infradead.org; Fri, 17 Dec 2021 09:41:03 +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 E33331435; Fri, 17 Dec 2021 01:40:58 -0800 (PST) Received: from [10.57.8.4] (unknown [10.57.8.4]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 08D623F774; Fri, 17 Dec 2021 01:40:56 -0800 (PST) Subject: Re: [PATCH 2/3] coresight: Fail to open with return stacks if they are unavailable To: Mike Leach Cc: Suzuki K Poulose , coresight@lists.linaro.org, Leo Yan , John Garry , Will Deacon , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Mathieu Poirier References: <20211208160907.749482-1-james.clark@arm.com> <20211208160907.749482-2-james.clark@arm.com> <20211210172220.GA1238770@p14s> From: James Clark Message-ID: Date: Fri, 17 Dec 2021 09:40:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211217_014101_916048_88EA09A0 X-CRM114-Status: GOOD ( 44.95 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 13/12/2021 09:48, Mike Leach wrote: > Hi James, > > A couple of points - relating mainly to docs: > Hi Mike, Thanks for the feedback. I was in the process of adding some docs and ran into this https://lkml.org/lkml/2021/12/16/1087 so I went to fix that first. Now I will add some more details and resubmit. > 1. Activating branch broadcast overrides any setting of return stack. > As a minimum there needs to be a documentation update to reflect this > -Setting both options is not prohibited in hardware - and in the case > where we can use branch broadcast over a range both are then relevant. > Do you mean that if branch broadcast and return stacks are both requested, but branch broadcast is limited to a range, return stacks will only be available outside that branch broadcast range? But if branch broadcast is enabled for all ranges there will be no return stacks at all? > 2. A documented note to reflect that choosing this option will result > in a significant increase in the amount of trace generated - possible > danger of overflows, or less actual instructions covered. In addition > perhaps documents could reflect the intended use-case for this option, > given the disadvantages. > Will do. > 3. Has this been tested in a situation where it will be of use? > Testing against static code images will show the same decoded trace > output as not using branch broadcast. (although the packet dumps will > show additional output)> > Given a primary use is for situations where code is patched or > dynamically altered at runtime - then this can affect the full decode > output. If the code is being patched to only alter the branch > addresses then decode should work against static images. > If, however, we are tracing code that adds in new branches, on top of > NOPs for example, then the decoding against the original static image > will be wrong, as the image will have the NOPs, rather than the branch > instructions so the apparent location of E atoms will be in a > different position to the actual code. Is there anything in perf that > will ensure that the patched code is presented to the decoder? > > If there are potential decode issues - these too need documenting. > I'm not sure this should be a blocking issue for this set. Branch broadcast could already be enabled by setting the mode via sysfs. And the perf decode part isn't necessarily a step in the workflow, maybe someone wants to gather data for another tool. I will do some testing after this change though, but I imagine we would have had issues reported it it wasn't working already which lowers the priority. James > Other than the documents and testing, I cannot see any issues with > this patch set in terms of setting and enabling the option. > > Regards > > Mike > > > On Fri, 10 Dec 2021 at 17:22, Mathieu Poirier > wrote: >> >> Hi James, >> >> On Thu, Dec 09, 2021 at 11:13:55AM +0000, James Clark wrote: >>> >>> >>> On 09/12/2021 11:00, Suzuki K Poulose wrote: >>>> On 08/12/2021 16:09, James Clark wrote: >>>>> Maintain consistency with the other options by failing to open when they >>>>> aren't supported. For example ETM_OPT_TS, ETM_OPT_CTXTID2 and the newly >>>>> added ETM_OPT_BRANCH_BROADCAST all return with -EINVAL if they are >>>>> requested but not supported by hardware. >>>>> >>>>> The consequence of not doing this is that the user may not be >>>>> aware that they are not enabling the feature as it is silently disabled. >>>>> >>>>> Signed-off-by: James Clark >>>>> --- >>>>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 13 +++++++++---- >>>>> 1 file changed, 9 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>> index d2bafb50c66a..0a9bb943a5e5 100644 >>>>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>>> @@ -674,10 +674,15 @@ static int etm4_parse_event_config(struct coresight_device *csdev, >>>>> } >>>>> /* return stack - enable if selected and supported */ >>>>> - if ((attr->config & BIT(ETM_OPT_RETSTK)) && drvdata->retstack) >>>>> - /* bit[12], Return stack enable bit */ >>>>> - config->cfg |= BIT(12); >>>>> - >>>>> + if (attr->config & BIT(ETM_OPT_RETSTK)) { >>>>> + if (!drvdata->retstack) { >>>>> + ret = -EINVAL; >>>>> + goto out; >>>>> + } else { >>>>> + /* bit[12], Return stack enable bit */ >>>>> + config->cfg |= BIT(12); >>>>> + } >>>> >>>> nit: While at this, please could you change the hard coded value >>>> to ETM4_CFG_BIT_RETSTK ? >>>> >>> I started changing them all because I had trouble searching for bits by name but then >>> I thought it would snowball into a bigger change so I undid it. >>> >>> I think I'll just go and do it now if it's an issue here. >> >> I can apply this set right away and you send another patch to fix all hard coded >> bitfields or you can send another revision with all 4 patches included in it >> (bitfields fix plus these 3). Just let me know what you want to do. And next >> time please add a cover letter. >> >> Thanks, >> Mathieu >> >>> >>>> Otherwise, looks good to me >>>> >>>> Suzuki > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel