Re: [Qemu-devel] [RFC][PATCH v3 00/24] instrument: Let the user wrap/override specific event tracing routines

[Lluís Vilanova]

Stefan Hajnoczi writes:

> On Wed, Apr 24, 2013 at 02:17:22PM +0200, Lluís Vilanova wrote:
> Thanks for explaining.

> People doing this level of instrumentation probably need to do QEMU
> hacking anyway for deep analysis, perhaps pausing and resuming the
> guest, checking other guest RAM locations, grabbing device state, maybe
> snapshotting the guest.

Some of these are already (or could easily be) available through QAPI, so
there's no need to "re-expose" them.


> Is it worth building and maintain a stable API?  It means that folks
> working on TCG, for example, do not have the freedom to change/delete
> trace events.  They are now stuck maintaining trace event semantics no
> matter how TCG will evolve in the future.

Well, the events added in future series (this one just adds the infrastructure)
are generic enough that TCG should just care about signalling, for example, when
an instruction/bbl starts. As this is in no way tied to the actual TCG
primitives, the internals are free to change.

What's probably less appropriate is exposing functions to generate TCG code to
the instrumentation libraries. This is what I added in one of my series, as it
allows the writing of highly-perfomant instrumentation routines, but I
understand it is undesirable (still, the library can just say "call this
function I wrote when the event happens", aka call a helper).


> It would be nice to make TCG multi-threaded soon.  How will
> instrumentation libraries handle this?  Existing ones probably won't,
> they'll break unless QEMU restricts itself back to single-threaded mode.

The only problem here is changing the dynamic callback of an event and flushing
the generated TCG code when a library is unloaded. That's the reason of one of
my TODO's at the top of this series, as I didn't dive enough into QEMU to handle
that.


> Given that the group of users for this feature is so small while the
> burden of supporting this is rather large, it seems like writing
> instrumentation code straight in a QEMU source tree is the most powerful
> and viable solution.

Well, the tracing event instrumentation support itself is quite generic and
should be maintainable, and can enormously simplify the task for others to use
it in the future.

>From my repository, the first three series (including this one) handle the
infrastructure, which is mostly based on providing tracetool backends.

The 4th one adds some very generic events (vbbl_{before,after},
vinst_{before,after}, vmem) that should have no ties to the TCG implementation.

The 5th one adds the backdoor we discussed long ago, which lets the guest code
interact with the instrumentation library, so that they can coordinate (AFAIR,
Blue said that could come in handy during tests, for example).

The next ones probably are more controversial, as they start adding new
interfaces available to the instrumentation libraries (as well as some extra
events).


> Basically I think putting a stable API in place here isn't going to fly.
> In terms of the tracing subsystem I don't mind, but I think it's a
> question for the larger QEMU community.

What are you referring to as an API? The tracing events and their signatures?


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth