From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYMdQ-0005Pu-82 for qemu-devel@nongnu.org; Wed, 07 Dec 2011 13:54:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYMdO-0004ap-8u for qemu-devel@nongnu.org; Wed, 07 Dec 2011 13:54:28 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:60820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYMdO-0004ak-4W for qemu-devel@nongnu.org; Wed, 07 Dec 2011 13:54:26 -0500 Received: by ggnk1 with SMTP id k1so1111724ggn.4 for ; Wed, 07 Dec 2011 10:54:25 -0800 (PST) Message-ID: <4EDFB65F.902@codemonkey.ws> Date: Wed, 07 Dec 2011 12:54:23 -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> <4EDFA6ED.20907@codemonkey.ws> <87pqg01b7w.fsf@ginnungagap.bsc.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: Peter Maydell Cc: Blue Swirl , Zhi Yong Wu , =?UTF-8?B?TGx1w61zIFZpbGFub3Zh?= , qemu-devel@nongnu.org On 12/07/2011 12:51 PM, Peter Maydell wrote: > 2011/12/7 Lluís Vilanova: >> Anthony Liguori writes: >> [...] >>> 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. >> >> For the same reason that SystemTap lets you add user-provided code into the >> trace hooks, you never know what the user actually wants. The difference is that >> when dealing with traces that require a high bandwidth, different people may be >> interested on analyzing different events and under different conditions, and >> having a JIT in QEMU comes in handy to optimize the traces. This includes the >> generation of extra tracing code at translation time (e.g., I generate checks in >> TCG to establish when I want to trace a specific event, and someone else may >> just want to increment a counter using TCG code). >> >> Guest trace instrumentation turns QEMU into a highly-performant tool for dynamic >> binary instrumentation, with all the benefits that stem from QEMU (support for a >> myriad of target architectures, as well as support for both full-system and >> user-level applications). > > I think this *is* useful. However I also think that it *is* effectively > defining an API for people writing this hook code, and as such we ought > to do it properly if we're going to do it. (ie nail down what we are > providing for hook authors and don't let them grub around in the internals > otherwise). I strongly suspect that you could define interfaces in QEMU such that you could do most of what you want without needing to link any code against QEMU itself. This is probably a case where LUA integration might make a lot of sense. Regards, Anthony Liguori > > -- PMM > >