From: Marc Zyngier <maz@kernel.org>
To: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Cc: Will Deacon <will@kernel.org>, <rostedt@goodmis.org>,
Catalin Marinas <catalin.marinas@arm.com>,
<quic_psodagud@quicinc.com>, <gregkh@linuxfoundation.org>,
<arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<mingo@redhat.com>, Prasad Sodagudi <psodagud@codeaurora.org>
Subject: Re: [PATCHv4 1/2] tracing: Add register read/write tracing support
Date: Fri, 19 Nov 2021 14:17:31 +0000 [thread overview]
Message-ID: <878rxk6xhg.wl-maz@kernel.org> (raw)
In-Reply-To: <6148397c-0565-d1ca-2f53-d15adcb9b6b8@quicinc.com>
On Fri, 19 Nov 2021 14:07:09 +0000,
Sai Prakash Ranjan <quic_saipraka@quicinc.com> wrote:
>
> On 11/19/2021 7:13 PM, Marc Zyngier wrote:
> > On Mon, 15 Nov 2021 11:33:29 +0000,
> > Sai Prakash Ranjan <quic_saipraka@quicinc.com> wrote:
> >> From: Prasad Sodagudi <psodagud@codeaurora.org>
> >>
[...]
> >> Reason why we wouldn't need value along with mmio write log is
> >> that value can be easily deduced from the caller_name+offset which is
> >> printed already by the rwmmio trace events which gives the exact
> >> location of mmio writes and the value is easily known from the driver.
> > That's a very narrow view of what can be written in an MMIO
> > registers. We write dynamic values at all times, and if we are able to
> > trace MMIO writes, then the value written out must be part of the trace.
> >
> > I'd rather you try and get to the bottom of this issue rather than
> > paper over it.
> >
> > Thanks,
> >
> > M.
> >
>
> Sure, idea was to put it out in the open if anyone has any idea as
> to what might be happening there since the version where directly
> instrumenting the raw read/write accessors in arm64/asm/io.h was
> working fine casting doubts if this has to do something with
> inlining as Arnd mentioned before.
Yup. I wouldn't be surprised if MMIO accessors were getting directly
inlined at the wrong location and creating havoc. For example:
writel(readl(addr1) | 1, addr2);
If you're not careful about capturing the result of the read rather
than the read itself, you can end-up with something really funky. No
idea if that's what is happening, but a disassembly of the generated
code could tell you.
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Cc: Will Deacon <will@kernel.org>, <rostedt@goodmis.org>,
Catalin Marinas <catalin.marinas@arm.com>,
<quic_psodagud@quicinc.com>, <gregkh@linuxfoundation.org>,
<arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<mingo@redhat.com>, Prasad Sodagudi <psodagud@codeaurora.org>
Subject: Re: [PATCHv4 1/2] tracing: Add register read/write tracing support
Date: Fri, 19 Nov 2021 14:17:31 +0000 [thread overview]
Message-ID: <878rxk6xhg.wl-maz@kernel.org> (raw)
In-Reply-To: <6148397c-0565-d1ca-2f53-d15adcb9b6b8@quicinc.com>
On Fri, 19 Nov 2021 14:07:09 +0000,
Sai Prakash Ranjan <quic_saipraka@quicinc.com> wrote:
>
> On 11/19/2021 7:13 PM, Marc Zyngier wrote:
> > On Mon, 15 Nov 2021 11:33:29 +0000,
> > Sai Prakash Ranjan <quic_saipraka@quicinc.com> wrote:
> >> From: Prasad Sodagudi <psodagud@codeaurora.org>
> >>
[...]
> >> Reason why we wouldn't need value along with mmio write log is
> >> that value can be easily deduced from the caller_name+offset which is
> >> printed already by the rwmmio trace events which gives the exact
> >> location of mmio writes and the value is easily known from the driver.
> > That's a very narrow view of what can be written in an MMIO
> > registers. We write dynamic values at all times, and if we are able to
> > trace MMIO writes, then the value written out must be part of the trace.
> >
> > I'd rather you try and get to the bottom of this issue rather than
> > paper over it.
> >
> > Thanks,
> >
> > M.
> >
>
> Sure, idea was to put it out in the open if anyone has any idea as
> to what might be happening there since the version where directly
> instrumenting the raw read/write accessors in arm64/asm/io.h was
> working fine casting doubts if this has to do something with
> inlining as Arnd mentioned before.
Yup. I wouldn't be surprised if MMIO accessors were getting directly
inlined at the wrong location and creating havoc. For example:
writel(readl(addr1) | 1, addr2);
If you're not careful about capturing the result of the read rather
than the read itself, you can end-up with something really funky. No
idea if that's what is happening, but a disassembly of the generated
code could tell you.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-19 14:17 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-15 11:33 [PATCHv4 0/2] tracing/rwmmio/arm64: Add support to trace register reads/writes Sai Prakash Ranjan
2021-11-15 11:33 ` Sai Prakash Ranjan
2021-11-15 11:33 ` [PATCHv4 1/2] tracing: Add register read/write tracing support Sai Prakash Ranjan
2021-11-15 11:33 ` Sai Prakash Ranjan
2021-11-19 13:43 ` Marc Zyngier
2021-11-19 13:43 ` Marc Zyngier
2021-11-19 14:07 ` Sai Prakash Ranjan
2021-11-19 14:07 ` Sai Prakash Ranjan
2021-11-19 14:17 ` Marc Zyngier [this message]
2021-11-19 14:17 ` Marc Zyngier
2021-11-19 15:19 ` Sai Prakash Ranjan
2021-11-19 15:19 ` Sai Prakash Ranjan
2021-11-15 11:33 ` [PATCHv4 2/2] arm64/io: Add a header for mmio access instrumentation Sai Prakash Ranjan
2021-11-15 11:33 ` Sai Prakash Ranjan
2021-11-16 22:40 ` Steven Rostedt
2021-11-16 22:40 ` Steven Rostedt
2021-11-17 3:53 ` Sai Prakash Ranjan
2021-11-17 3:53 ` Sai Prakash Ranjan
2021-11-18 14:58 ` kernel test robot
2021-11-18 14:58 ` kernel test robot
2021-11-18 14:58 ` kernel test robot
2021-11-18 15:24 ` Arnd Bergmann
2021-11-18 15:24 ` Arnd Bergmann
2021-11-19 4:06 ` Sai Prakash Ranjan
2021-11-19 4:06 ` Sai Prakash Ranjan
2021-11-22 13:35 ` Sai Prakash Ranjan
2021-11-22 13:35 ` Sai Prakash Ranjan
2021-11-22 13:59 ` Arnd Bergmann
2021-11-22 13:59 ` Arnd Bergmann
2021-11-22 14:19 ` Sai Prakash Ranjan
2021-11-22 14:19 ` Sai Prakash Ranjan
2021-11-22 14:30 ` Arnd Bergmann
2021-11-22 14:30 ` Arnd Bergmann
2021-11-22 14:59 ` Sai Prakash Ranjan
2021-11-22 14:59 ` Sai Prakash Ranjan
2021-11-22 15:35 ` Arnd Bergmann
2021-11-22 15:35 ` Arnd Bergmann
2021-11-22 15:43 ` Sai Prakash Ranjan
2021-11-22 15:43 ` Sai Prakash Ranjan
2021-11-29 13:49 ` Sai Prakash Ranjan
2021-11-29 13:49 ` Sai Prakash Ranjan
2021-11-19 13:48 ` Marc Zyngier
2021-11-19 13:48 ` Marc Zyngier
2021-11-19 14:09 ` Sai Prakash Ranjan
2021-11-19 14:09 ` Sai Prakash Ranjan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rxk6xhg.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=psodagud@codeaurora.org \
--cc=quic_psodagud@quicinc.com \
--cc=quic_saipraka@quicinc.com \
--cc=rostedt@goodmis.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.