Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/07/2011 10:59 AM, Lluís Vilanova wrote:
> 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.

Why should this analyzer live outside of QEMU in the first place?  I fail to see 
the rationale for that other than not wanting to do the work of making it 
suitable for upstream consumption.

Regards,

Anthony Liguori