Anthony Liguori writes:
Well, both backdoor and trace instrumentation are implemented using the same
approach (a static library selected at compile-time). The user sets which events
to instrument in the "trace-events" file. This has the effect that the tracetool
script will not generate the tracing functions for those events, and instead the
user must provide the implementation for these events on a static library
provided at compile time.
I don't think this is the right approach to tracing. What not just use
something like SystemTap to implement logic around tracing?
http://blog.vmsplice.net/2011/03/how-to-write-trace-analysis-scripts-for.html
This would only allow me to post-process all the traces, with no possible
interaction with qemy from the analysis library.
Compiling the analysis library into qemu itself lets me control when TCG code to
actually trace an instruction is generated (with guest code, trace events are
instrumented at both code translation and code execution time):
translate:
gen_helper_trace_mem(...)
-- trace instrumentation --> ... if (...)
gen_helper_trace_mem_backend(...); ...
-- otherwise --> gen_helper_trace_mem_backend(...);
execute:
helper_trace_mem(...)
trace_mem(...)
-- trace instrumentation --> ... whatever ...
-- otherwise --> trace_fetch_backend(...);
One could argue that gen_helper_trace_mem can just check some in-qemu central
structure to see if it must generate the call to helper_trace_mem, but then the
best you can do is an all-or-nothing on a per-event basis.
You must have in mind that we're talking about an extreme tracing bandwidth
here, so the analyzer is willing to filter-out as many events as soon as
possible (e.g., just tracing a specific set of IPs can be optimized at
translation time, and tracing instructions using specific registers can be
optimized by generating extra checks with TCG). This requires some sort of
in-line communication between qemu and the analyzer.