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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23E0EC433EF for ; Mon, 18 Oct 2021 21:16:54 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C020F6112D for ; Mon, 18 Oct 2021 21:16:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C020F6112D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding: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=kAW686GQJiSmmddwm3eV+4jd12Q8NF0NZYlTo+q7Ovk=; b=xqGALfFf+lPEd+VCOoSxr2/apN zfJ8xQ3dkltS4+la82hZUuCf2LmgYJ5a1ppMDcXAkiFGwBqq2uFtRRQyzOel8uUM1uYPYIO4pdMoL FSBEDPTW8gJhHTy8DeQ/EAujkvzmRUvQBd0wag/YaoSMR4J+RqJGKYpLieCGrKpyXnaPi5609stRc mETtFzig1dHMvSo1fWlvEOCzme6mbChXX/yMcVidWJIwqDLiS9AQq0mL3VaegnUC+H13F/SNCL3DC 9UZMnCbRATJs4IvmIgU9xkcq3fDkfUW/wxxXpZi0hdxuh3XOuVoC34GAU3MvifBaT1DojJ0m9RzwC BrOFEvpg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mcZyw-00HJH7-NG; Mon, 18 Oct 2021 21:15:42 +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 1mcZyr-00HJFP-Sm for linux-arm-kernel@lists.infradead.org; Mon, 18 Oct 2021 21:15:39 +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 A2D0AD6E; Mon, 18 Oct 2021 14:15:35 -0700 (PDT) Received: from [10.57.25.70] (unknown [10.57.25.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 203773F73D; Mon, 18 Oct 2021 14:15:33 -0700 (PDT) Subject: Re: [PATCH v5 10/15] coresight: trbe: Workaround TRBE errata overwrite in FILL mode To: Mathieu Poirier Cc: will@kernel.org, catalin.marinas@arm.com, anshuman.khandual@arm.com, mike.leach@linaro.org, leo.yan@linaro.org, maz@kernel.org, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20211014223125.2605031-1-suzuki.poulose@arm.com> <20211014223125.2605031-11-suzuki.poulose@arm.com> <20211018155154.GB3163131@p14s> From: Suzuki K Poulose Message-ID: Date: Mon, 18 Oct 2021 22:15:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211018155154.GB3163131@p14s> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211018_141538_062695_2A72DA13 X-CRM114-Status: GOOD ( 21.43 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 18/10/2021 16:51, Mathieu Poirier wrote: > On Thu, Oct 14, 2021 at 11:31:20PM +0100, Suzuki K Poulose wrote: >> ARM Neoverse-N2 (#2139208) and Cortex-A710(##2119858) suffers from >> an erratum, which when triggered, might cause the TRBE to overwrite >> the trace data already collected in FILL mode, in the event of a WRAP. >> i.e, the TRBE doesn't stop writing the data, instead wraps to the base >> and could write upto 3 cache line size worth trace. Thus, this could >> corrupt the trace at the "BASE" pointer. >> >> The workaround is to program the write pointer 256bytes from the >> base, such that if the erratum is triggered, it doesn't overwrite >> the trace data that was captured. This skipped region could be >> padded with ignore packets at the end of the session, so that >> the decoder sees a continuous buffer with some padding at the >> beginning. The trace data written at the base is considered >> lost as the limit could have been in the middle of the perf >> ring buffer, and jumping to the "base" is not acceptable. >> We set the flags already to indicate that some amount of trace >> was lost during the FILL event IRQ. So this is fine. >> >> One important change with the work around is, we program the >> TRBBASER_EL1 to current page where we are allowed to write. >> Otherwise, it could overwrite a region that may be consumed >> by the perf. Towards this, we always make sure that the >> "handle->head" and thus the trbe_write is PAGE_SIZE aligned, >> so that we can set the BASE to the PAGE base and move the >> TRBPTR to the 256bytes offset. >> >> Cc: Mike Leach >> Cc: Mathieu Poirier >> Cc: Anshuman Khandual >> Cc: Leo Yan >> Reviewed-by: Mathieu Poirier >> Signed-off-by: Suzuki K Poulose >> --- >> Changes since v2: >> - Updated the ASCII art to include better description of >> all the steps in the work around >> Change since v1: >> - Updated comment with ASCII art >> - Add _BYTES suffix for the space to skip for the work around. >> --- >> drivers/hwtracing/coresight/coresight-trbe.c | 169 +++++++++++++++++-- >> 1 file changed, 158 insertions(+), 11 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c >> index 314e5e7374c7..b56b166b2dec 100644 >> --- a/drivers/hwtracing/coresight/coresight-trbe.c >> +++ b/drivers/hwtracing/coresight/coresight-trbe.c >> @@ -16,6 +16,7 @@ >> #define pr_fmt(fmt) DRVNAME ": " fmt >> >> #include >> +#include > > Here too I get a checkpatch warning... > That is a false alarm. I guess that warns for including linux/cpufeature.h? It is a bit odd, we include this for the arm64 cpucaps, not the generic linux feature checks. (They are used for "loading modules" based on "features" which are more like ELF HWCAPs). As such I chose to ignore it. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel