[lttng-dev] [Qemu-devel] [PATCH 0/6] hypertrace: Lightweight guest-to-QEMU trace channel

[Lluís Vilanova]

Daniel P Berrange writes:

> On Mon, Aug 29, 2016 at 08:46:02PM +0200, Lluís Vilanova wrote:
>> Stefan Hajnoczi writes:
>> 
>> > When SystemTap is used the QEMU monitor interface does nothing.
>> 
>> That's not what I've experienced. I was able to use a stap script to change the
>> tracing state of events:
>> 
>> #!/usr/bin/env stap
>> 
>> %{
>> #include </home/lluis/Projects/qemu-dbi-test/test.h>
>> %}
>> 
>> function event:long(cpu:long, addr:long, info:long)
>> %{
>> char *argv[4] = {"/bin/sh", "-c", "echo 'trace-event * off' | telnet localhost 1234", NULL};
>> call_usermodehelper(argv[0], argv, NULL, UMH_WAIT_EXEC);
>> STAP_RETURN(0);
>> %}

> I don't know what you're trying to achieve here.  The trace-event state,
> as changed/viewed via QEMU monitor, is irrelevant to the dtrace (systemtap)
> backend. dtrace and ltt-ust are both fully dynamic trace event backends,
> so the QEMU event state has no effect on them. The probe points in the
> binary are dynamically enabled / disabled by the dtrace runtime. ie dtrace
> will automatically enable an event if you write a dtrace script that uses
> the event.

Sorry, I did not properly explain the use case. This is an example of using
QEMU's tracing infrastructure to control itself. Here I'm using the "log"
backend to trace events to disk, and the "dtrace" backend (systemtap) to control
the tracing state of such events.

The guest code is something like:

  // some guest code executed *without* tracing enabled

  invoke_hypertrace_event(); // stap will enable some events here

  // some guest code executed *with* tracing enabled

  invoke_hypertrace_event(); // stap will disable some events here

  // some guest code executed *without* tracing enabled

So we can use it to mark regions of interest for tracing.


Cheers,
  Lluis