From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYJjK-00022U-TY for qemu-devel@nongnu.org; Wed, 07 Dec 2011 10:48:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYJjF-00079B-In for qemu-devel@nongnu.org; Wed, 07 Dec 2011 10:48:22 -0500 Received: from mail-fx0-f45.google.com ([209.85.161.45]:51901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYJjF-00078h-BM for qemu-devel@nongnu.org; Wed, 07 Dec 2011 10:48:17 -0500 Received: by faao26 with SMTP id o26so195527faa.4 for ; Wed, 07 Dec 2011 07:48:16 -0800 (PST) Message-ID: <4EDF8ABB.7010208@codemonkey.ws> Date: Wed, 07 Dec 2011 09:48:11 -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> In-Reply-To: <87obvkqucc.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 09:23 AM, Lluís Vilanova wrote: > Anthony Liguori writes: > [...] >>>> If you want to extend QEMU, then send proper patches. Adding random C files to >>>> the build is unacceptable. >>> >>> What do you mean by proper patches? > >> If you want to add "custom functionality" to QEMU, send a patch to upstream QEMU. > > See below. > > >>> The whole point of this is to ease the >>> process for the user to add custom guest-to-qemu interactions, so there is no >>> "proper implementation" here. > >> That's too vague as far as I'm concerned. The only reason I can see to have a >> mechanism like this is 1) to avoid pushing stuff upstream and/or 2) to >> circumvent QEMU licensing by shipping a separate file that the user includes >> themselves. > > AFAIK, GPL licensing restrictions only apply when the code is shipped in a > binary blob. If this is the case, the library is statically included in qemu, so > it must still comply with the licensing requirements of qemu. Still, take this > with a grain of salt as I'm not a licensing expert. > > My motivation is more like 1 (I'll release the analyzer library I'm developing > once it's finished), but for the reasons stated below. > > >> I see no reason to encourage either of these things. It also creates an >> inevitable problem of internal API stability. What happens when the tree >> changes and all of these "custom guest-to-qemu interactions" break? > >> You may claim that it's an unsupported interface, but what will actually happen >> is that users will start depending on these custom features long after the >> initial developer has stopped caring. > >>> Blue Swirl already mentioned this can be used for testing qemu itself, while my >>> use case is coupled with the trace instrumentation features (I'll probably send >>> the first batch today). > >> In terms of supporting this mechanism, all backend code needs to live in >> upstream QEMU. That's a hard requirement. No configure flags to pull in random >> C files and no dlopens. > >> If you resent the series doing that, it'd be more likely to be merged but since >> I don't think your intention is to push backend code into QEMU, I wonder whether >> it's worth really merging this mechanism at all. > >> If this is just infrastructure that is only used by private forks, I don't think >> it belongs upstream. > > 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 > The analyses one might want to perform are ad-hoc in nature. For example, some > recent work sent here did coverage analyses through ad-hoc modifications on the > core of qemu, I want to generate detailed traces of the guest code that is > executed (although only when certain conditions in the guest are met). There is > no silver bullet here, but the development of analyzers can be simplified by > letting users perform static instrumentation of the tracing events, which act as > regular tracing events otherwise. > > In this environment, the backdoor is just a handy channel to let the guest > communicate with code on that analyzer library, like signalling semanticful > events of interest (e.g., I have a trivial linux kernel module that installs a > tracepoint callback in the process switch routine and passes that information > down to the analyzer library through the backdoor channel). > > As these analyzes are ad-hoc in nature, I don't see any way other than providing > this extension functionality. But the effect is that the infrastructure is useless without out-of-tree code which means it's impossible to test. Furthermore, when the ad-hoc analyzer library breaks because of an API change in QEMU, it puts us in a very difficult situation. > > Does it make sense as a whole? I thought from previous mails that being able to > trace and analyze guest code was something perceived as a useful feature to have > in qemu. I think there's wide agreement that extending tracing to guests is very useful and something we should do. I don't think there's agreement that we should have a mechanism to pull in third-party code to implement the logic for these trace hooks within QEMU. The right way to do analysis is via something like SystemTap. Regards, Anthony Liguori > > > Lluis >