[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
Date: Wed, 07 Dec 2011 11:48:29 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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?


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):

       -- trace instrumentation -->   ... if (...) 
gen_helper_trace_mem_backend(...); ...
       -- otherwise             -->   gen_helper_trace_mem_backend(...);

         -- 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.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]