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 X-Spam-Level: X-Spam-Status: No, score=-7.6 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C0C6C433EF for ; Tue, 7 Sep 2021 09:19:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4E7A5610F8 for ; Tue, 7 Sep 2021 09:19:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245210AbhIGJUS (ORCPT ); Tue, 7 Sep 2021 05:20:18 -0400 Received: from foss.arm.com ([217.140.110.172]:33626 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244918AbhIGJUG (ORCPT ); Tue, 7 Sep 2021 05:20:06 -0400 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 8BDB131B; Tue, 7 Sep 2021 02:19:00 -0700 (PDT) Received: from [10.57.94.84] (unknown [10.57.94.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C4C7F3F766; Tue, 7 Sep 2021 02:18:58 -0700 (PDT) Subject: Re: [PATCH 08/10] coresight: trbe: Workaround TRBE errat overwrite in FILL mode To: Linu Cherian Cc: linux-arm-kernel , Mark Rutland , maz@kernel.org, Anshuman Khandual , catalin.marinas@arm.com, Coresight ML , linux-kernel@vger.kernel.org, james.morse@arm.com, Will Deacon , Mike Leach References: <20210728135217.591173-1-suzuki.poulose@arm.com> <20210728135217.591173-9-suzuki.poulose@arm.com> From: Suzuki K Poulose Message-ID: Date: Tue, 7 Sep 2021 10:18:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linu On 06/08/2021 17:09, Linu Cherian wrote: > Hi Suzuki, > > On Wed, Jul 28, 2021 at 7:23 PM 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. > > Just trying to understand, > Is there a possibility that lost data results in partial trace packets > towards the end of the buffer ? Or its always guaranteed that > trace packet end is always aligned with buffer end/limit ? > Thinking of a case when formatting is disabled. Yes, trace could be partial towards the end with TRBE in the FILL mode. The TRBE doesn't add any formatting and is thus raw ETE trace which doesn't have any alignment requirements. This the case even without the work around. 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 X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5308DC433F5 for ; Tue, 7 Sep 2021 09:20:55 +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 17FD0610FE for ; Tue, 7 Sep 2021 09:20:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 17FD0610FE 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=MceLBsYQq1hZkC4zNuUGolEIKmUBHdEMch4pNA9IJLw=; b=yA0JjaYBmkiCl/XN+JwVjx/TY+ 0eLPR7rylRm81SfOquPAgN5M7Gv+jxsJ9moEMStymOgGqr9VxyfDU+n7Qy3O2RJ/9l7wWSpeboxdE hXIEP85A9jpucFblOMr6GpUUi9oeG6l0u3YDCdb7CJqMlFr+jVi5DaXMwN8+CgigbSARbYxL++J35 SPTs6Azi4lSmfkHNT0qkkOkVpoac6o5ANeO11she5y4rdxD4K/BmtWLF1XWO6sXLUt/hXPisTE9fR nnKTYYLiCB/ncMhQho0yrthtx6t6AZye3og3fMBchruoiq+gAiIfYXhFDc7/r1k5p/dcmAEv74c8+ kCxqyTVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mNXG2-0038KY-Vh; Tue, 07 Sep 2021 09:19:11 +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 1mNXFy-0038JG-BA for linux-arm-kernel@lists.infradead.org; Tue, 07 Sep 2021 09:19:07 +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 8BDB131B; Tue, 7 Sep 2021 02:19:00 -0700 (PDT) Received: from [10.57.94.84] (unknown [10.57.94.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C4C7F3F766; Tue, 7 Sep 2021 02:18:58 -0700 (PDT) Subject: Re: [PATCH 08/10] coresight: trbe: Workaround TRBE errat overwrite in FILL mode To: Linu Cherian Cc: linux-arm-kernel , Mark Rutland , maz@kernel.org, Anshuman Khandual , catalin.marinas@arm.com, Coresight ML , linux-kernel@vger.kernel.org, james.morse@arm.com, Will Deacon , Mike Leach References: <20210728135217.591173-1-suzuki.poulose@arm.com> <20210728135217.591173-9-suzuki.poulose@arm.com> From: Suzuki K Poulose Message-ID: Date: Tue, 7 Sep 2021 10:18:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210907_021906_498251_808F360D X-CRM114-Status: GOOD ( 19.70 ) 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 Hi Linu On 06/08/2021 17:09, Linu Cherian wrote: > Hi Suzuki, > > On Wed, Jul 28, 2021 at 7:23 PM 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. > > Just trying to understand, > Is there a possibility that lost data results in partial trace packets > towards the end of the buffer ? Or its always guaranteed that > trace packet end is always aligned with buffer end/limit ? > Thinking of a case when formatting is disabled. Yes, trace could be partial towards the end with TRBE in the FILL mode. The TRBE doesn't add any formatting and is thus raw ETE trace which doesn't have any alignment requirements. This the case even without the work around. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel