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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>