From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYLbi-0002zq-FF for qemu-devel@nongnu.org; Wed, 07 Dec 2011 12:48:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYLbe-0008Cb-9k for qemu-devel@nongnu.org; Wed, 07 Dec 2011 12:48:38 -0500 Received: from mail-ey0-f173.google.com ([209.85.215.173]:47877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYLbd-0008CI-TK for qemu-devel@nongnu.org; Wed, 07 Dec 2011 12:48:34 -0500 Received: by eaai10 with SMTP id i10so835412eaa.4 for ; Wed, 07 Dec 2011 09:48:32 -0800 (PST) Message-ID: <4EDFA6ED.20907@codemonkey.ws> Date: Wed, 07 Dec 2011 11:48:29 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20111205222208.31271.65662.stgit@ginnungagap.bsc.es> <4EDE9CBE.9080707@codemonkey.ws> <87ehwgvah0.fsf@ginnungagap.bsc.es> <4EDF703E.20401@codemonkey.ws> <87obvkqucc.fsf@ginnungagap.bsc.es> <4EDF8ABB.7010208@codemonkey.ws> <87aa74gvxj.fsf@ginnungagap.bsc.es> In-Reply-To: <87aa74gvxj.fsf@ginnungagap.bsc.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Llu=EDs_Vilanova?= Cc: Blue Swirl , Zhi Yong Wu , qemu-devel@nongnu.org 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