From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60880 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3xB9-0005TF-2U for qemu-devel@nongnu.org; Thu, 07 Oct 2010 16:35:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P3xB6-0003XK-Ug for qemu-devel@nongnu.org; Thu, 07 Oct 2010 16:35:02 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:49377 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1P3xB6-0003WV-Io for qemu-devel@nongnu.org; Thu, 07 Oct 2010 16:35:00 -0400 From: xscript@gmx.net (=?utf-8?Q?Llu=C3=ADs?=) Subject: Re: [Qemu-devel] [STATUS] static instrumentation References: <8762xdyhha.fsf@ginnungagap.bsc.es> Date: Thu, 07 Oct 2010 22:34:56 +0200 In-Reply-To: (Blue Swirl's message of "Thu, 7 Oct 2010 19:23:29 +0000") Message-ID: <87mxqpn3m7.fsf@ginnungagap.bsc.es> MIME-Version: 1.0 Content-Type: text/plain List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Blue Swirl writes: > The patches there seem to be fixes or small changes to your other > patches. This makes any review very difficult. Sorry, I'm really new to git, so I don't really know how to maintain and "grow" an organized set of patches for review while I keep improving the work. > But I'm not sure the architecture is what we'd like to see integrated > in QEMU, though I may have missed the whole picture because of the > patch fragmentation problem. Before doing any work to possibly go > further in wrong direction, please try to submit early some preview > version for comments and review. I can try to refactor the changes into a sensible set of patches, but please read first the motivation of this work (below). > Just as an example, perhaps the existing tracing framework could be > extended to cover also your needs. Well, for what I've seen of the tracing infrastructure ("tracing" from here on), it is geared towards tracing qemu internal events (for analyzing qemu performance), while static instrumentation ("instrumentation" from here on) is geared towards tracing guest events, in order to analyze guest behaviour. The reason for having static instrumentation points in the form of macros (diverging from the approach taken in tracing) is that the most common instrumentation points are invoked at code generation time. This way the user can dynamically select which extra code to call and/or generate (if any) on each of these points, with the addition that code can be selected for regeneration when the instrumentation points need to produce different code (e.g., no instrumentation, event counting, sketchy trace generation, detailed trace generation, etc.). So, I think they are geared towards different goals, although they are indeed composable (e.g., the user can expand the instrumentation macros into calls to the tracing infrastructure). Wether or not this fits into upstream qemu is not for me to say, but it provides the initial stepping stone that is commonly used in computer architecture research (e.g., http://www.ptlsim.org or http://sesc.sourceforge.net/), with the added bonus that qemu supports multiple ISAs, as well as executing standalone applications and a full-fledged system. Of course, the simulator itself would be out of qemu, thus the macros :) Lluis -- "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