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 438CEC433F5 for ; Tue, 9 Nov 2021 13:55:41 +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 F274F6124D for ; Tue, 9 Nov 2021 13:55:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F274F6124D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org 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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JuqnbORCN9ab7R+6gC9EMSrVrT1r6nCBSrwfMS8vx68=; b=A9bDyI+YQAQVi8 CSiE2uJq/AdFxPXhbrDgZikZFItoVuJiTPK9I2KpQ5Zp74eyS5Ss9k/v3SL64UiGhNloX0iNQDRTK QPaFI9ZU0pY3OwWGplsCtaSd5v3hkoAOhHhdZupPrl0Ww6dQLUouKoAtrv01JeaTt5dTaKgaaPtdK ZwAJ1TRdPNV8Vq5MeIbffiqOiUrRARVPq7r4O0Tv55sfGPDz0ZU/UbvV1ZBzc932dErmSUPjRBU+C O4ZLYdO7vuAE82v7umdge+3Fam5Y6/4+JNcOcCEcBYkl90ZtzwUZwhuSqXsZWs9BDEhOvkCPt5XD0 YsnLIXvf7Ec0qWqDG+4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkRZq-002MQo-Uz; Tue, 09 Nov 2021 13:54:19 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkRZm-002MPr-Hm for linux-arm-kernel@lists.infradead.org; Tue, 09 Nov 2021 13:54:16 +0000 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6F175610A2; Tue, 9 Nov 2021 13:54:12 +0000 (UTC) Date: Tue, 9 Nov 2021 08:54:10 -0500 From: Steven Rostedt To: Sai Prakash Ranjan Cc: Will Deacon , Catalin Marinas , , Marc Zyngier , , , , , , , , , "Prasad Sodagudi" Subject: Re: [PATCHv3 1/3] tracing: Add register read/write tracing support Message-ID: <20211109085410.349edffa@gandalf.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211109_055414_656244_A2FDD1D4 X-CRM114-Status: GOOD ( 28.03 ) 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 Tue, 9 Nov 2021 17:38:19 +0530 Sai Prakash Ranjan wrote: > From: Prasad Sodagudi > > Generic MMIO read/write i.e., __raw_{read,write}{b,l,w,q} accessors > are typically used to read/write from/to memory mapped registers > and can cause hangs or some undefined behaviour in following few > cases, > > * If the access to the register space is unclocked, for example: if > there is an access to multimedia(MM) block registers without MM > clocks. > > * If the register space is protected and not set to be accessible from > non-secure world, for example: only EL3 (EL: Exception level) access > is allowed and any EL2/EL1 access is forbidden. > > * If xPU(memory/register protection units) is controlling access to > certain memory/register space for specific clients. > > and more... > > Such cases usually results in instant reboot/SErrors/NOC or interconnect > hangs and tracing these register accesses can be very helpful to debug > such issues during initial development stages and also in later stages. > > So use ftrace trace events to log such MMIO register accesses which > provides rich feature set such as early enablement of trace events, > filtering capability, dumping ftrace logs on console and many more. > > Sample output: > > rwmmio_read: gic_peek_irq+0xd0/0xd8 readl addr=0xffff800010040104 > rwmmio_write: gic_poke_irq+0xe4/0xf0 writel addr=0xffff800010040184 val=0x40 > rwmmio_read: gic_do_wait_for_rwp+0x54/0x90 readl addr=0xffff800010040000 > rwmmio_write: gic_set_affinity+0x1bc/0x1e8 writeq addr=0xffff800010046130 val=0x500 > > Signed-off-by: Prasad Sodagudi > [saiprakash: Rewrote commit msg and trace event field edits] > Signed-off-by: Sai Prakash Ranjan > --- > include/trace/events/rwmmio.h | 61 ++++++++++++++++++++++++++++++++++ > kernel/trace/Kconfig | 7 ++++ > kernel/trace/Makefile | 1 + > kernel/trace/trace_readwrite.c | 28 ++++++++++++++++ > 4 files changed, 97 insertions(+) > create mode 100644 include/trace/events/rwmmio.h > create mode 100644 kernel/trace/trace_readwrite.c > > diff --git a/include/trace/events/rwmmio.h b/include/trace/events/rwmmio.h > new file mode 100644 > index 000000000000..cb5261a559f8 > --- /dev/null > +++ b/include/trace/events/rwmmio.h > @@ -0,0 +1,61 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (c) 2021 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > +#undef TRACE_SYSTEM > +#define TRACE_SYSTEM rwmmio > + > +#if !defined(_TRACE_MMIO_H) || defined(TRACE_HEADER_MULTI_READ) > +#define _TRACE_MMIO_H > + > +#include > + > +TRACE_EVENT(rwmmio_write, > + > + TP_PROTO(unsigned long fn, const char *width, u64 val, volatile void __iomem *addr), > + > + TP_ARGS(fn, width, val, addr), > + > + TP_STRUCT__entry( > + __field(u64, fn) > + __string(width, width) > + __field(u64, val) > + __field(u64, addr) For better space usage, move the __string to the end. Each of the u64 fields will take up 8 bytes, and the __string only takes up 4 (it's a 2 byte offset and 2 byte length, where the actual string lies at the end of the event). Many archs will leave a 4 byte "hole" between the __string() field and the u64 val field. If __string is at the end, it will go nicely with the actual string that will be appended behind it. > + ), > + > + TP_fast_assign( > + __entry->fn = fn; > + __assign_str(width, width); > + __entry->val = val; > + __entry->addr = (u64)addr; > + ), > + > + TP_printk("%pS %s addr=%#llx val=%#llx", > + (void *)__entry->fn, __get_str(width), __entry->addr, __entry->val) > +); > + > +TRACE_EVENT(rwmmio_read, > + > + TP_PROTO(unsigned long fn, const char *width, const volatile void __iomem *addr), > + > + TP_ARGS(fn, width, addr), > + > + TP_STRUCT__entry( > + __field(u64, fn) > + __string(width, width) > + __field(u64, addr) Same here. > + ), > + > + TP_fast_assign( > + __entry->fn = fn; > + __assign_str(width, width); > + __entry->addr = (u64)addr; > + ), > + > + TP_printk("%pS %s addr=%#llx", > + (void *)__entry->fn, __get_str(width), __entry->addr) > +); > + -- Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel