On Fri, Aug 05, 2016 at 06:59:23PM +0200, Lluís Vilanova wrote:
> The hypertrace channel allows guest code to emit events in QEMU (the host) using
> its tracing infrastructure (see "docs/trace.txt"). This works in both 'system'
> and 'user' modes. That is, hypertrace is to tracing, what hypercalls are to
> system calls.
> 
> You can use this to emit an event on both guest and QEMU (host) traces to easily
> synchronize or correlate them. You could also modify you guest's tracing system
> to emit all events through the hypertrace channel, providing a unified and fully
> synchronized trace log. Another use case is timing the performance of guest code
> when optimizing TCG (QEMU traces have a timestamp).
> 
> See first commit for a full description.

This tracing approach has a high performance overhead, particularly for
SMP guests where each trace event requires writing to the global control
register.  All CPUs will be hammering this register (heavyweight vmexit)
for each trace event.

I think the folks CCed on this email all take an asynchronous approach
to avoid this performance overhead.  Synchronous means taking a VM exit
for every event.  Asynchronous means writing trace data to a buffer and
later interleaving guest data with host trace data.

LTTng Userspace Tracer is an example of the asynchronous approach.  The
trace data buffers are in shared memory.  The LTTng process can grab
buffers at appropriate times.

The ftrace virtio-serial approach has been to splice() the ftrace
buffers, resulting in efficient I/O.

Steven is working on a host/guest solution for trace-cmd.  It is also
asynchronous.  No new paravirt hardware is needed and it makes me wonder
whether the hypertrace PCI device is trying to solve the problem at the
wrong layer.

If you want to play around with asynchronous tracing, you could start
with trace/simple.c.  It has a trace buffer that is asynchronously
written out to file by a dedicated "writer" thread.

The one case where hypertrace makes sense to me is for -user tracing.
There QEMU can efficiently interleave guest and QEMU traces, although as
mentioned in the patch, I don't think the SIGSEGV approach should be
used.

I suggest stripping this series down to focus on -user.  Synchronous
tracing is not a good approach for -system emulation.

Stefan