Trace Agent for virtio-trace
============================

Trace agent is a user tool for sending trace data of a guest to a Host in low
overhead. Trace agent has the following functions:
 - splice a page of ring-buffer to read_pipe without memory copying
 - splice the page from write_pipe to virtio-console without memory copying
 - write trace data to stdout by using -o option
 - controlled by start/stop orders from a Host

The trace agent operates as follows:
 1) Initialize all structures.
 2) Create a read/write thread per CPU. Each thread is bound to a CPU.
    The read/write threads hold it.
 3) A controller thread does poll() for a start order of a host.
 4) After the controller of the trace agent receives a start order from a host,
    the controller wake read/write threads.
 5) The read/write threads start to read trace data from ring-buffers and
    write the data to virtio-serial.
 6) If the controller receives a stop order from a host, the read/write threads
    stop to read trace data.


Files
=====

README: this file
Makefile: Makefile of trace agent for virtio-trace
trace-agent.c: includes main function, sets up for operating trace agent
trace-agent.h: includes all structures and some macros
trace-agent-ctl.c: includes controller function for read/write threads
trace-agent-rw.c: includes read/write threads function


Setup
=====

To use this trace agent for virtio-trace, we need to prepare some virtio-serial
I/Fs.

1) Make FIFO in a host
 virtio-trace uses virtio-serial pipe as trace data paths as to the number
of CPUs and a control path, so FIFO (named pipe) should be created as follows:
	# mkdir /tmp/virtio-trace/
	# mkfifo /tmp/virtio-trace/trace-path-cpu{0,1,2,...,X}.{in,out}
	# mkfifo /tmp/virtio-trace/agent-ctl-path.{in,out}

For example, if a guest use three CPUs, the names are
	trace-path-cpu{0,1,2}.{in.out}
and
	agent-ctl-path.{in,out}.

2) Set up of virtio-serial pipe in a host
 Add qemu option to use virtio-serial pipe.

 ##virtio-serial device##
     -device virtio-serial-pci,id=virtio-serial0\
 ##control path##
     -chardev pipe,id=charchannel0,path=/tmp/virtio-trace/agent-ctl-path\
     -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,\
      id=channel0,name=agent-ctl-path\
 ##data path##
     -chardev pipe,id=charchannel1,path=/tmp/virtio-trace/trace-path-cpu0\
     -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,\
      id=channel1,name=trace-path-cpu0\
      ...

If you manage guests with libvirt, add the following tags to domain XML files.
Then, libvirt passes the same command option to qemu.

	<channel type='pipe'>
	   <source path='/tmp/virtio-trace/agent-ctl-path'/>
	   <target type='virtio' name='agent-ctl-path'/>
	   <address type='virtio-serial' controller='0' bus='0' port='0'/>
	</channel>
	<channel type='pipe'>
	   <source path='/tmp/virtio-trace/trace-path-cpu0'/>
	   <target type='virtio' name='trace-path-cpu0'/>
	   <address type='virtio-serial' controller='0' bus='0' port='1'/>
	</channel>
	...
Here, chardev names are restricted to trace-path-cpuX and agent-ctl-path. For
example, if a guest use three CPUs, chardev names should be trace-path-cpu0,
trace-path-cpu1, trace-path-cpu2, and agent-ctl-path.

3) Boot the guest
 You can find some chardev in /dev/virtio-ports/ in the guest.


Run
===

0) Build trace agent in a guest
	$ make

1) Enable ftrace in the guest
 <Example>
	# echo 1 > /sys/kernel/debug/tracing/events/sched/enable

2) Run trace agent in the guest
 This agent must be operated as root.
	# ./trace-agent
read/write threads in the agent wait for start order from host. If you add -o
option, trace data are output via stdout in the guest.

3) Open FIFO in a host
	# cat /tmp/virtio-trace/trace-path-cpu0.out
If a host does not open these, trace data get stuck in buffers of virtio. Then,
the guest will stop by specification of chardev in QEMU. This blocking mode may
be solved in the future.

4) Start to read trace data by ordering from a host
 A host injects read start order to the guest via virtio-serial.
	# echo 1 > /tmp/virtio-trace/agent-ctl-path.in

5) Stop to read trace data by ordering from a host
 A host injects read stop order to the guest via virtio-serial.
	# echo 0 > /tmp/virtio-trace/agent-ctl-path.in
8cc1ab5c4517d916edaed9e3f7f973'>5aff1d245e8cc1ab5c4517d916edaed9e3f7f973</a> (<a href='/cgit.cgi/linux/net-next.git/patch/?id=5aff1d245e8cc1ab5c4517d916edaed9e3f7f973'>patch</a>)</td></tr>
<tr><th>tree</th><td colspan='2' class='oid'><a href='/cgit.cgi/linux/net-next.git/tree/?id=5aff1d245e8cc1ab5c4517d916edaed9e3f7f973'>6f212c10ca8245be6bb1dd43f83ebb9bf7452d6a</a></td></tr>
<tr><th>parent</th><td colspan='2' class='oid'><a href='/cgit.cgi/linux/net-next.git/commit/?id=a47b3fca62a34e5956fc9b61065083e9c055d50f'>a47b3fca62a34e5956fc9b61065083e9c055d50f</a> (<a href='/cgit.cgi/linux/net-next.git/diff/?id=5aff1d245e8cc1ab5c4517d916edaed9e3f7f973&amp;id2=a47b3fca62a34e5956fc9b61065083e9c055d50f'>diff</a>)</td></tr></table>
<div class='commit-subject'>ARM: defconfigs: make NF_CT_PROTO_SCTP and NF_CT_PROTO_UDPLITE built-in</div><div class='commit-msg'>The symbols can no longer be used as loadable modules, leading to a harmless Kconfig
warning:

arch/arm/configs/imote2_defconfig:60:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
arch/arm/configs/imote2_defconfig:59:warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP
arch/arm/configs/ezx_defconfig:68:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
arch/arm/configs/ezx_defconfig:67:warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP

Let's make them built-in.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</div><div class='diffstat-header'><a href='/cgit.cgi/linux/net-next.git/diff/?id=5aff1d245e8cc1ab5c4517d916edaed9e3f7f973'>Diffstat</a></div><table summary='diffstat' class='diffstat'>