[Qemu-devel] [RFC 0/2] Tracing

[Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>]

Trace events in QEMU/KVM can be very useful for debugging and performance
analysis.  I'd like to discuss tracing support and hope others have an interest
in this feature, too.

Following this email are patches I am using to debug virtio-blk and storage.
The patches provide trivial tracing support, but they don't address the details
of real tracing tools: enabling/disabling events at runtime, no overhead for
disabled events, multithreading support, etc.

It would be nice to have userland tracing facilities that work out-of-the-box
on production systems.  Unfortunately, I'm not aware of any such facilities out
there right now on Linux.  Perhaps SystemTap userspace tracing is the way to
go, has anyone tried it with KVM?

For the medium term, without userspace tracing facilities in the OS we could
put something into QEMU to address the need for tracing.  Here are my thoughts
on fleshing out the tracing patch I have posted:

1. Make it possible to enable/disable events at runtime.  Users enable only the
   events they are interested in and aren't flooded with trace data for all
   other events.

2. Either make trace events cheap or build without trace events by default.
   Disable by default still allows tracing to be used for development but
   less for production.

3. Allow events in any execution context (cpu, io, aio emulation threads).  The
   current code does not support concurrency and is meant for when the iothread
   mutex is held.

4. Make it easy to add new events.  Instead of keeping trace.h and trace.py in
   sync manually, use something like .hx to produce the appropriate C and
   Python.

Summary: Tracing is useful, are there external tools we can use right now?  If
not, should we put in something that works well enough until external tools
catch up?

Stefan