Daniel P Berrange writes: > On Mon, Sep 05, 2016 at 08:29:54PM +0200, Lluís Vilanova wrote: >> 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.
> Ah, I see. I guess I'd personally just have systemtap/dtrace directly emit > the data to be recorded, and avoid the log backend entirely. Backends with a buffered output stream like "simple" should be faster than "dtrace", which AFAIK injects a software trap. Also, you can take advantage of existing QEMU infrastructure to control the tracing of events, instead of implementing your own on each script. Cheers, Lluis