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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
