From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBUaq-0000Z0-OV for qemu-devel@nongnu.org; Thu, 06 Feb 2014 14:26:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBUad-0005d6-HR for qemu-devel@nongnu.org; Thu, 06 Feb 2014 14:26:36 -0500 Received: from roura.ac.upc.es ([147.83.33.10]:41629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBUad-0005cc-6H for qemu-devel@nongnu.org; Thu, 06 Feb 2014 14:26:23 -0500 From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= References: <20140131160902.32741.2680.stgit@fimbulvetr.bsc.es> <52F0FFBD.8050801@twiddle.net> <87k3davcs3.fsf@fimbulvetr.bsc.es> <52F3B105.80908@twiddle.net> Date: Thu, 06 Feb 2014 20:26:18 +0100 In-Reply-To: <52F3B105.80908@twiddle.net> (Richard Henderson's message of "Thu, 06 Feb 2014 07:57:57 -0800") Message-ID: <87a9e411r9.fsf@fimbulvetr.bsc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 00/12] trace: [tcg] Allow tracing guest events in TCG-generated code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Richard Henderson writes: > On 02/04/2014 12:33 PM, Llu=C3=ADs Vilanova wrote: >> Richard Henderson writes: >>=20 >>> On 01/31/2014 08:09 AM, Llu=C3=ADs Vilanova wrote: >>>> Adds the base ability to specify which events in the "trace-events" fi= le may be >>>> used to trace guest activity in the TCG code (using the "tcg" event pr= opery). >>>>=20 >>>> Such events generate an extra set of tracing functions that can be cal= led during >>>> TCG code generation and will automatically redirect a call to the appr= opriate >>>> backend-dependent tracing functions when the guest code is executed. >>>>=20 >>>> Files generating guest code (TCG) must include "trace-tcg.h". Files de= claring >>>> per-target helpers ("${target}/helper.h") must include >>>> "trace/generated-helpers.h". >>>>=20 >>>> The flow of the generated routines is: >>>>=20 >>>>=20 >>>> [At translation time] >>>>=20 >>>> * trace_${name}_tcg(bool, TCGv) >>>> Declared: "trace/generated-tcg-tracers.h" >>>> Defined : "trace/generated-tcg-tracers.h" >>>>=20 >>>> * gen_helper_trace_${name}_tcg(bool, TCGv) >>>> Declared: "trace/generated-helpers.h" >>>> Defined : "trace/generated-helpers.h" >>>>=20 >>>> Automatically transforms all the arguments and allocates them into the >>>> appropriate TCG temporary values (which are also freed). Provides a mo= re >>>> streamlined interface by allowing events in "trace-events" to take a m= ix of >>>> tracing-supported types and TCG types. >>>>=20 >>>> * gen_helper_trace_${name}_tcg_proxy(TCGi32, TCGv) >>>> Declared: "trace/generated-helpers.h" >>>> Defined : "trace/generated-helpers.h" (using helper machinery) >>>>=20 >>>> The actual TCG helper function, created using QEMU's TCG helper machin= ery. >>=20 >>> I suppose I have no major objection to the feature, although frankly it= 's >>> not especially exciting. I can't really imagine ever wanting to bulk t= race >>> all of the helpers. Tracing specific helpers on a target-by-target bas= is, >>> sure. But that can be done just as easily as adding tracing code to any >>> other bit of C. >>=20 >> I'm not sure I understand this comment. The patch does not add helper tr= acing >> capabilities, but generates a "trace_foo_tcg" routine that can be called= during >> TCG code generation, and will call "trace_foo" when that TCG code is >> executed. > Ah, see, I told you I was probably reading the patches wrong. With all t= he > helpers.h changes, I thought this was somehow related to tracing the exis= ting > helpers. But the existance of trace_foo_tcg is triggered by the trace-ev= ents file? Yes, defining "tcg foo" in the "trace-events" file will generate the functi= ons described in this series. >>> I would strongly suggest this is backward. One should perform the chec= k for >>> the tracepoint being enabled at translation time before emitting the ca= ll to >>> the helper in the first place. >>=20 >> Right, the thing is that dynamically enabling/disabling such events will= not >> immediately show up in the trace if I do the check at translation time >> (trace_foo_tcg), since QEMU will execute the cached TCG translations. I = see the >> following solutions to ensure traces are accurate: >>=20 >> * Delay the check until execution time. >>=20 >> * Check at translation time; flush translation cache when the tracing st= ate of >> a TCG event changes. >>=20 >> * Check at translation time; use multiple translation caches, one for ea= ch >> possible tracing state of all the TCG-enabled events. >>=20 >> This series implements the first approach, since it's correct and much >> simpler. >>=20 >> Other patches I did not send implement the third approach, which is quite >> efficient if one is dynamically switching the tracing state while execut= ing >> mostly-cached code (e.g., profiling the accesses). > How often do events change state? My guess is exceedingly rarely. > And by "rare" I mean something well under once per minute. ;-) > At which point, option 2 would be the best bet, I think. Right. For the 3rd option I was also thinking about having per-vCPU tracing states (in the case of guest events), so that you can trace separate events depending on the vCPU. Which reminds me, I should add a vCPU pointer to the "guest_vmem" event, si= nce otherwise you cannot differentiate accesses among different vCPUs. >> I can wait for a later series to send the third option, or even implemen= t the >> second, but I just wanted to keep this one as simple as possible. Also, >> implementing any of these two last approaches would provide minimal over= heads on >> builds that have such events enabled at compile time. > Fair enough. Thanks, Lluis --=20 "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth