[Qemu-devel] Reg. trace infrastructure

[Qemu-devel] Reg. trace infrastructure

[Sripathi Kodi]

Hi Stefan, Prerna,

I pulled down QEMU tracing code from git://repo.or.cz/qemu/stefanha.git
and tried to use it to trace something in virtio-9p code. I don't have
any knowledge of how traces are implemented and I just went with the
documentation. With help from Prerna, I was able to insert a trace
point and observe it getting hit from the QEMU monitor. However, I have
a few questions about this. Could you please help me out?

*) My understanding is the traces are dumped to a file only when the
trace buffer gets filled. Is there a way to: 
  a) Forcibly dump the contents of the buffer when needed.
  b) When QEMU exits it should dump the buffer. Doesn't seem to be
  doing this now.
  c) A way to specify the file into which it writes the traces.

*) Is QEMU monitor the only way to enable/disable trace points? Is it
possible to programmatically enable/disable trace points from within
QEMU code? If that is not possible, is it possible to specify all trace
points to be enabled in a text file and ask QEMU to read the file when
it starts up?

*) Is it possible to enable/disable a bunch of trace points at one
shot? Can trace points be grouped in some way? Can I say "enable all
trace points in a particular .c file" or "enable all trace points in
these 2 functions"?

Thanks a lot for your help.

-Sripathi.

[Qemu-devel] Re: Reg. trace infrastructure

[Stefan Hajnoczi]

On Mon, Jul 05, 2010 at 10:39:19PM +0530, Sripathi Kodi wrote:
> Hi Stefan, Prerna,
> 
> I pulled down QEMU tracing code from git://repo.or.cz/qemu/stefanha.git
> and tried to use it to trace something in virtio-9p code. I don't have
> any knowledge of how traces are implemented and I just went with the
> documentation. With help from Prerna, I was able to insert a trace
> point and observe it getting hit from the QEMU monitor. However, I have
> a few questions about this. Could you please help me out?

Great, thanks for trying out tracing.  This is useful feedback and is
going to help us decide what to work on next.

> *) My understanding is the traces are dumped to a file only when the
> trace buffer gets filled. Is there a way to: 
>   a) Forcibly dump the contents of the buffer when needed.

There is currently no way to do this.

>   b) When QEMU exits it should dump the buffer. Doesn't seem to be
>   doing this now.

I will add a commit to fix this.  Once the buffer can be dumped out on
exit it should also be easy to add a monitor command to do this any
time (solves point a).

>   c) A way to specify the file into which it writes the traces.

There is currently no way to do this.  I think we need a trace file
management command, something like:

trace start <filename>  Opens a trace file
trace stop              Flushes and closes the trace file
trace flush             Flushes the trace buffer to the file

Prerna also has a patch to inspect the trace buffer in memory - before
it is flushed to file.  I'm not sure how we want to integrate this with
the trace file management command.

> *) Is QEMU monitor the only way to enable/disable trace points? Is it
> possible to programmatically enable/disable trace points from within
> QEMU code? If that is not possible, is it possible to specify all trace
> points to be enabled in a text file and ask QEMU to read the file when
> it starts up?

These are good ideas.  There is currently no "enable virtio_*" wildcard
support and even that wouldn't allow enabling/disable per source file.
Trace events could be grouped (e.g. by file) or even tagged if this
feature is desirable.  Currently the trace-events file already has
comments naming the source files of each group of trace events.

Programmatically enabling/disabling trace events is possible with:

#include "trace.h"

change_trace_event_state("virtio_irq", true); /* enable */
[...]
change_trace_event_state("virtio_irq", false); /* disable */

I like the idea of loading a list of trace events to enable on startup.
We need to support both tracing from startup and toggling trace events
at runtime.

> *) Is it possible to enable/disable a bunch of trace points at one
> shot? Can trace points be grouped in some way? Can I say "enable all
> trace points in a particular .c file" or "enable all trace points in
> these 2 functions"?

Not yet, explained more above.

There is still a ways to go before tracing is usable.  Thanks for
sharing your ideas!  Today we created a skeleton wiki page where I hope
we can plan which use cases and commands should be possible:

http://wiki.qemu.org/Features/Tracing

Stefan