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=-5.3 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 72084C5519F for ; Mon, 23 Nov 2020 03:41:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 1F1A120738 for ; Mon, 23 Nov 2020 03:41:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eV4Qg6jp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F1A120738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Fe5DaL/A8EmGHiQDR/VqhniVH6Dv3jXM3OaqvWDujCE=; b=eV4Qg6jpZ8n9cHAygiMEDAzPr T3ssgSC2DP9ZyNe1wfuWWmPovIokkmrfQDfUnFu8E+5MDP6apyEbb4ERUzv4RjwxrVhFZEfCfECfj tANh9ljziW/pjTtuNFwuLVJSVXsYI5w3d2A8jQbikz2VAPYJDZLrUy44YOCI+mW7E5+wv9Cv2yon5 DPvK+11Jms0i8o0f56zdpi9oMm+BS3jKAQP+FddCf+egN33RKi8J1Zc/hQ2guCvdu2FSSJ6vcxgt8 LbXVyUOg48Rr6IsUokWBM8FBlQlKx/75QtVtYroNNkgF7JYb0Nxl3OmWDnE5ljyUju1TUYzFU6oLT +qR/uxXmw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kh2i2-0000id-6g; Mon, 23 Nov 2020 03:40:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kh2hy-0000hx-Ac for linux-arm-kernel@lists.infradead.org; Mon, 23 Nov 2020 03:40: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 A95BF30E; Sun, 22 Nov 2020 19:40:04 -0800 (PST) Received: from [10.163.82.200] (unknown [10.163.82.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D95A83F70D; Sun, 22 Nov 2020 19:40:02 -0800 (PST) Subject: Re: [RFC 00/11] arm64: coresight: Enable ETE and TRBE To: Mike Leach , Tingwei Zhang References: <1605012309-24812-1-git-send-email-anshuman.khandual@arm.com> <20201114051715.GA23685@codeaurora.org> From: Anshuman Khandual Message-ID: Date: Mon, 23 Nov 2020 09:10:00 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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-20201122_224006_488315_0D03C6A9 X-CRM114-Status: GOOD ( 31.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Coresight ML , Linux Kernel Mailing List , linux-arm-kernel 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 Hello Mike, On 11/16/20 8:30 PM, Mike Leach wrote: > Hi Anshuman, > > I've not looked in detail at this set yet, but having skimmed through > it I do have an initial question about the handling of wrapped data > buffers. > > With the ETR/ETB we found an issue with the way perf concatenated data > captured from the hardware buffer into a single contiguous data > block. The issue occurs when a wrapped buffer appears after another > buffer in the data file. In a typical session perf would stop trace > and copy the hardware buffer multiple times into the auxtrace buffer. The hardware buffer and perf aux trace buffer are the same for TRBE and hence there is no actual copy involved. Trace data gets pushed into the user space via perf_aux_output_end() either via etm_event_stop() or via the IRQ handler i.e arm_trbe_irq_handler(). Data transfer to user space happens via updates to perf aux buffer indices i.e head, tail, wake up. But logically, they will appear as a stream of records to the user space while parsing perf.data file. > > e.g. > > For ETR/ETB we have a fixed length hardware data buffer - and no way > of detecting buffer wraps using interrupts as the tracing is in > progress. TRBE has an interrupt. Hence there will be an opportunity to insert any additional packets if required to demarcate pre and post IRQ trace data streams. > > If the buffer is not full at the point that perf transfers it then the > data will look like this:- > 1) > easy to decode, we can see the async at the start of the data - which > would be the async issued at the start of trace. Just curious, what makes the tracer to generate the trace packet. Is there an explicit instruction or that is how the tracer starts when enabled ? > > If the buffer wraps we see this:- > > 2) > > Again no real issue, the decoder will skip to the async and trace from > there - we lose the unsynced data. Could you please elaborate more on the difference between sync and async trace data ? > > Now the problem occurs when multiple transfers of data occur. We can > see the following appearing as contiguous trace in the auxtrace > buffer:- > > 3) < async> So there is an wrap around event between and ? Are there any other situations where this might happen ? > > Now the decoder cannot spot the point that the synced data from the > first capture ends, and the unsynced data from the second capture > begins. Got it. > This means it will continue to decode into the unsynced data - which > will result in incorrect trace / outright errors. To get round this > for ETR/ETB the driver will insert barrier packets into the datafile > if a wrap event is detected. But you mentioned there are on IRQs on ETR/ETB. So how the wrap event is even detected ? > > 4) data> > > This has the effect of resetting the decoder into the > unsynced state so that the invalid trace is not decoded. This is a > workaround we have to do to handle the limitations of the ETR / ETB > trace hardware. Got it. > > For TRBE we do have interrupts, so it should be possible to prevent > the buffer wrapping in most cases - but I did see in the code that > there are handlers for the TRBE buffer wrap management event. Are > there other factors in play that will prevent data pattern 3) from > appearing in the auxtrace buffer ? On TRBE, the buffer wrapping cannot happen without generating an IRQ. I would assume that ETE will then start again with an data packet first when the handler returns. Otherwise we might also have to insert a similar barrier packet for the user space tool to reset. As trace data should not get lost during an wrap event, ETE should complete the packet after the handler returns, hence aux buffer should still have logically contiguous stream of to decode. I am not sure right now, but will look into this. - Anshuman _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel