Re: [Qemu-devel] [STATUS] static instrumentation

[Blue Swirl]

On Thu, Oct 7, 2010 at 8:34 PM, Lluís <address@hidden> wrote:
> Blue Swirl writes:
>
>> The patches there seem to be fixes or small changes to your other
>> patches. This makes any review very difficult.
>
> Sorry, I'm really new to git, so I don't really know how to maintain and
> "grow" an organized set of patches for review while I keep improving the
> work.

Some kind of patch queue or stack tool can help, I use StGit
(integrates nicely with QGit) but there are others.

The workflow should aim for a set of committable patches. This means
that instead of patch sequence
1 - implement feature A
2 - fix for feature A
3 - implement feature B
4 - more fixes for feature A
5 - fixes for feature B

etc, the patches should be perfected, like this:
1 - implement feature A
2 - implement feature B

This can be achieved by working with the patch stack:
1 - implement feature A
fix for feature A needed: fix, refresh 1
2 - implement feature B
more fixes for feature A needed: pop 2, include fixes to 1
fixes for feature B: push 2, fix and refresh 2

This also makes keeping up with HEAD simpler (though conflicts need to
be managed anyway):
pop all patches
git pull
push patches one at a time, fix conflicts if needed.

>> But I'm not sure the architecture is what we'd like to see integrated
>> in QEMU, though I may have missed the whole picture because of the
>> patch fragmentation problem. Before doing any work to possibly go
>> further in wrong direction, please try to submit early some preview
>> version for comments and review.
>
> I can try to refactor the changes into a sensible set of patches, but
> please read first the motivation of this work (below).
>
>
>> Just as an example, perhaps the existing tracing framework could be
>> extended to cover also your needs.
>
> Well, for what I've seen of the tracing infrastructure ("tracing" from
> here on), it is geared towards tracing qemu internal events (for
> analyzing qemu performance), while static instrumentation
> ("instrumentation" from here on) is geared towards tracing guest events,
> in order to analyze guest behaviour.
>
> The reason for having static instrumentation points in the form of
> macros (diverging from the approach taken in tracing) is that the most
> common instrumentation points are invoked at code generation time. This
> way the user can dynamically select which extra code to call and/or
> generate (if any) on each of these points, with the addition that code
> can be selected for regeneration when the instrumentation points need to
> produce different code (e.g., no instrumentation, event counting,
> sketchy trace generation, detailed trace generation, etc.).
>
> So, I think they are geared towards different goals, although they are
> indeed composable (e.g., the user can expand the instrumentation macros
> into calls to the tracing infrastructure).

Maybe the goals are different, but even with this description, I don't
see why tracing could not be extended also to generated code (again, I
don't know the instrumentation side). From QEMU code maintenance point
of view, a unified approach would be much preferable to two different,
overlapping systems.

> Wether or not this fits into upstream qemu is not for me to say, but it
> provides the initial stepping stone that is commonly used in computer
> architecture research (e.g., http://www.ptlsim.org or
> http://sesc.sourceforge.net/), with the added bonus that qemu supports
> multiple ISAs, as well as executing standalone applications and a
> full-fledged system.
>
> Of course, the simulator itself would be out of qemu, thus the macros :)

Is the simulator available? Otherwise testing would be difficult.