From: Pekka Paalanen <pq@iki.fi>
To: Eugene Shatokhin <euspectre@gmail.com>
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: MmioTrace: Using the Instruction Decoder, etc.
Date: Thu, 17 Oct 2013 19:46:14 +0300 [thread overview]
Message-ID: <20131017194614.64a6b70e@farn.lan> (raw)
In-Reply-To: <CAL5fWtDBJUT0sK+rT9fD+BbFtwPuF4oBCUo8Gs+_aRMH4R_p=w@mail.gmail.com>
On Mon, 14 Oct 2013 22:45:09 +0400
Eugene Shatokhin <euspectre@gmail.com> wrote:
> Hi,
>
> There is an interesting TODO item on MmioTraceDeveloper page:
> "kprobes has a generic instruction decoding facility, use that instead of
> homebrewn (or KVM), and use emulation instead of page faulting"
>
> Actually, I have done something similar in one of my systems, KernelStrider
> (http://code.google.com/p/kernel-strider/). The system instruments a kernel
> module when that module is being loaded. The instrumented code executes
> instead of the original one and provides information about the memory
> accesses it makes and the functions it calls. These data are sent to user
> space for further analysis.
>
> Currently, I use this system to detect data races in the Linux kernel (and
> have found some). I suppose, it could probably be useful to MmioTrace as
> well.
>
> KernelStrider uses an enhanced version of the x86 instruction decoder that
> Kprobes use and relies on binary instrumentation rather than on page
> faults. So, it can track:
> - memory accesses (address and size of the accessed memory as well as the
> access type are recorded)
> - function calls (exported functions and callbacks, one can setup pre- and
> post- handlers for these)
>
> Is there any interest in trying this approach to the task of MmioTrace?
>
> If so, we can discuss it. When I have time, I could try to create a
> prototype based on KernelStrider's core that tracks the memory accesses
> Mmiotrace needs.
> What do you think?
Hi Eugene,
that is very interesting! I assume emulating the instructions is
not only cleaner, but also faster than page-faulting, right? Maybe
even more reliable, perhaps up to the point where we would not need
to disable all but one CPU.
Unfortunately, my job exhausts my coding energy, and I haven't even
touched mmiotrace in years.
However, let's see if there are interested people on the mailing
lists. I'm CC'ing nouveau, since that is where mmiotrace started,
and dri-devel in the hopes to catch other drivers' reverse
engineers.
Thanks,
pq
next parent reply other threads:[~2013-10-17 16:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAL5fWtDBJUT0sK+rT9fD+BbFtwPuF4oBCUo8Gs+_aRMH4R_p=w@mail.gmail.com>
2013-10-17 16:46 ` Pekka Paalanen [this message]
2013-10-17 20:11 ` MmioTrace: Using the Instruction Decoder, etc Eugene Shatokhin
2013-10-19 7:14 ` Pekka Paalanen
[not found] ` <20131019101417.50a33eaf-DA5HUFbJnAM@public.gmane.org>
2013-10-19 13:12 ` Eugene Shatokhin
2013-10-25 9:08 ` Pekka Paalanen
[not found] ` <20131025120846.277e85aa-DA5HUFbJnAM@public.gmane.org>
2013-10-25 13:19 ` Eugene Shatokhin
2013-10-28 11:30 ` Pekka Paalanen
[not found] ` <20131028133049.65adf92e-DA5HUFbJnAM@public.gmane.org>
2013-10-28 18:57 ` Eugene Shatokhin
2013-10-19 13:16 ` Eugene Shatokhin
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=20131017194614.64a6b70e@farn.lan \
--to=pq@iki.fi \
--cc=dri-devel@lists.freedesktop.org \
--cc=euspectre@gmail.com \
--cc=nouveau@lists.freedesktop.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.