From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYkrH-0001pv-Lh for qemu-devel@nongnu.org; Thu, 08 Dec 2011 15:46:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYkrG-00081x-2g for qemu-devel@nongnu.org; Thu, 08 Dec 2011 15:46:23 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:45740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYkrF-00081m-Vk for qemu-devel@nongnu.org; Thu, 08 Dec 2011 15:46:22 -0500 Received: by iafj26 with SMTP id j26so3522144iaf.4 for ; Thu, 08 Dec 2011 12:46:21 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4EDFB65F.902@codemonkey.ws> 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> <4EDFB65F.902@codemonkey.ws> From: Blue Swirl Date: Thu, 8 Dec 2011 20:45:59 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Anthony Liguori Cc: Zhi Yong Wu , Peter Maydell , =?UTF-8?Q?Llu=C3=ADs_Vilanova?= , qemu-devel@nongnu.org On Wed, Dec 7, 2011 at 18:54, Anthony Liguori wrote= : > On 12/07/2011 12:51 PM, Peter Maydell wrote: >> >> 2011/12/7 Llu=C3=ADs Vilanova: >>> >>> Anthony Liguori writes: >>> [...] >>>> >>>> Why should this analyzer live outside of QEMU in the first place? =C2= =A0I >>>> 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 differenc= e >>> is that >>> when dealing with traces that require a high bandwidth, different peopl= e >>> 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 includ= es >>> 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 els= e >>> may >>> just want to increment a counter using TCG code). >>> >>> Guest trace instrumentation turns QEMU into a highly-performant tool fo= r >>> 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 interna= ls >> 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 Q= EMU > itself. I don't see linking as the problem, the instrumenting user who modifies QEMU needs to follow licensing if the result is ever distributed. But the API issue can be a problem. Reusing and extending tracepoints should help API stability from an instrumenting user point of view and a rich set of various static and dynamic tracepoint mechanisms should only be helpful for development of QEMU. But also I agree that the internals of QEMU shouldn't become an API for any user code which happens to access them. > This is probably a case where LUA integration might make a lot of sense. > > Regards, > > Anthony Liguori > >> >> -- PMM >> >> >