mmiotrace.rst 6.8 KB
Newer Older
1 2 3
===================================
In-kernel memory-mapped I/O tracing
===================================
4 5 6 7


Home page and links to optional user space tools:

8
	https://nouveau.freedesktop.org/wiki/MmioTrace
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

MMIO tracing was originally developed by Intel around 2003 for their Fault
Injection Test Harness. In Dec 2006 - Jan 2007, using the code from Intel,
Jeff Muizelaar created a tool for tracing MMIO accesses with the Nouveau
project in mind. Since then many people have contributed.

Mmiotrace was built for reverse engineering any memory-mapped IO device with
the Nouveau project as the first real user. Only x86 and x86_64 architectures
are supported.

Out-of-tree mmiotrace was originally modified for mainline inclusion and
ftrace framework by Pekka Paalanen <pq@iki.fi>.


Preparation
-----------

Mmiotrace feature is compiled in by the CONFIG_MMIOTRACE option. Tracing is
disabled by default, so it is safe to have this set to yes. SMP systems are
supported, but tracing is unreliable and may miss events if more than one CPU
is on-line, therefore mmiotrace takes all but one CPU off-line during run-time
30 31
activation. You can re-enable CPUs by hand, but you have been warned, there
is no way to automatically detect if you are losing events due to CPUs racing.
32 33 34 35


Usage Quick Reference
---------------------
36
::
37

38 39 40 41 42 43 44
	$ mount -t debugfs debugfs /sys/kernel/debug
	$ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer
	$ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt &
	Start X or whatever.
	$ echo "X is up" > /sys/kernel/debug/tracing/trace_marker
	$ echo nop > /sys/kernel/debug/tracing/current_tracer
	Check for lost events.
45 46 47 48 49


Usage
-----

R
Randy Dunlap 已提交
50
Make sure debugfs is mounted to /sys/kernel/debug.
51 52 53
If not (requires root privileges)::

	$ mount -t debugfs debugfs /sys/kernel/debug
54 55 56

Check that the driver you are about to trace is not loaded.

57 58 59 60 61 62 63
Activate mmiotrace (requires root privileges)::

	$ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer

Start storing the trace::

	$ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt &
64 65 66 67 68 69 70

The 'cat' process should stay running (sleeping) in the background.

Load the driver you want to trace and use it. Mmiotrace will only catch MMIO
accesses to areas that are ioremapped while mmiotrace is active.

During tracing you can place comments (markers) into the trace by
71
$ echo "X is up" > /sys/kernel/debug/tracing/trace_marker
72 73 74 75
This makes it easier to see which part of the (huge) trace corresponds to
which action. It is recommended to place descriptive markers about what you
do.

76 77 78 79
Shut down mmiotrace (requires root privileges)::

	$ echo nop > /sys/kernel/debug/tracing/current_tracer

80 81 82
The 'cat' process exits. If it does not, kill it by issuing 'fg' command and
pressing ctrl+c.

83 84 85 86 87 88 89 90
Check that mmiotrace did not lose events due to a buffer filling up. Either::

	$ grep -i lost mydump.txt

which tells you exactly how many events were lost, or use::

	$ dmesg

91 92 93
to view your kernel log and look for "mmiotrace has lost events" warning. If
events were lost, the trace is incomplete. You should enlarge the buffers and
try again. Buffers are enlarged by first seeing how large the current buffers
94 95 96 97
are::

	$ cat /sys/kernel/debug/tracing/buffer_size_kb

98
gives you a number. Approximately double this number and write it back, for
99 100 101 102
instance::

	$ echo 128000 > /sys/kernel/debug/tracing/buffer_size_kb

103
Then start again from the top.
104 105

If you are doing a trace for a driver project, e.g. Nouveau, you should also
106 107 108 109 110 111
do the following before sending your results::

	$ lspci -vvv > lspci.txt
	$ dmesg > dmesg.txt
	$ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt

112 113
and then send the .tar.gz file. The trace compresses considerably. Replace
"pciid" and "nick" with the PCI ID or model name of your piece of hardware
R
Randy Dunlap 已提交
114
under investigation and your nickname.
115 116 117 118 119 120 121 122


How Mmiotrace Works
-------------------

Access to hardware IO-memory is gained by mapping addresses from PCI bus by
calling one of the ioremap_*() functions. Mmiotrace is hooked into the
__ioremap() function and gets called whenever a mapping is created. Mapping is
R
Randy Dunlap 已提交
123
an event that is recorded into the trace log. Note that ISA range mappings
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144
are not caught, since the mapping always exists and is returned directly.

MMIO accesses are recorded via page faults. Just before __ioremap() returns,
the mapped pages are marked as not present. Any access to the pages causes a
fault. The page fault handler calls mmiotrace to handle the fault. Mmiotrace
marks the page present, sets TF flag to achieve single stepping and exits the
fault handler. The instruction that faulted is executed and debug trap is
entered. Here mmiotrace again marks the page as not present. The instruction
is decoded to get the type of operation (read/write), data width and the value
read or written. These are stored to the trace log.

Setting the page present in the page fault handler has a race condition on SMP
machines. During the single stepping other CPUs may run freely on that page
and events can be missed without a notice. Re-enabling other CPUs during
tracing is discouraged.


Trace Log Format
----------------

The raw log is text and easily filtered with e.g. grep and awk. One record is
R
Randy Dunlap 已提交
145 146
one line in the log. A record starts with a keyword, followed by keyword-
dependent arguments. Arguments are separated by a space, or continue until the
147 148
end of line. The format for version 20070824 is as follows:

R
Randy Dunlap 已提交
149
Explanation	Keyword	Space-separated arguments
150 151 152 153 154 155 156 157 158
---------------------------------------------------------------------------

read event	R	width, timestamp, map id, physical, value, PC, PID
write event	W	width, timestamp, map id, physical, value, PC, PID
ioremap event	MAP	timestamp, map id, physical, virtual, length, PC, PID
iounmap event	UNMAP	timestamp, map id, PC, PID
marker		MARK	timestamp, text
version		VERSION	the string "20070824"
info for reader	LSPCI	one line from lspci -v
R
Randy Dunlap 已提交
159
PCI address map	PCIDEV	space-separated /proc/bus/pci/devices data
160 161 162 163 164 165 166 167 168 169
unk. opcode	UNKNOWN	timestamp, map id, physical, data, PC, PID

Timestamp is in seconds with decimals. Physical is a PCI bus address, virtual
is a kernel virtual address. Width is the data width in bytes and value is the
data value. Map id is an arbitrary id number identifying the mapping that was
used in an operation. PC is the program counter and PID is process id. PC is
zero if it is not recorded. PID is always zero as tracing MMIO accesses
originating in user space memory is not yet supported.

For instance, the following awk filter will pass all 32-bit writes that target
170 171
physical addresses in the range [0xfb73ce40, 0xfb800000]
::
172

173 174
	$ awk '/W 4 / { adr=strtonum($5); if (adr >= 0xfb73ce40 &&
	adr < 0xfb800000) print; }'
175 176 177 178 179 180


Tools for Developers
--------------------

The user space tools include utilities for:
181 182
  - replacing numeric addresses and values with hardware register names
  - replaying MMIO logs, i.e., re-executing the recorded writes
183 184