[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU back

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
Date: Wed, 07 Dec 2011 09:48:11 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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 

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

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?


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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]