[Top][All Lists]

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

Re: [Qemu-devel] [RFC][PATCH v3 00/24] instrument: Let the user wrap/ove

From: Lluís Vilanova
Subject: Re: [Qemu-devel] [RFC][PATCH v3 00/24] instrument: Let the user wrap/override specific event tracing routines
Date: Wed, 01 May 2013 16:34:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Stefan Hajnoczi writes:

> On Sun, Apr 28, 2013 at 09:25:15PM +0200, Lluís Vilanova wrote:
>> Stefan Hajnoczi writes:
>> > On Fri, Apr 26, 2013 at 02:15:46PM +0200, Lluís Vilanova wrote:
>> > Advanced users will have to modify the QEMU source.
>> >> > 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?
>> > The interface that dynamic instrumentation libraries use to interact
>> > with QEMU.  That means "stable" tracing events plus any operations that
>> > libraries can perform (stop/stop vcpu, peek/poke memory, dirty bitmaps,
>> > MMU, interrupts, etc).
>> Not all events require being "stable", just a few that I established as
>> "abstract" and relate to some very generic guest state (which in their most
>> basic form can be boiled down to 5). As for the rest of the API and more
>> controversial events, as I said I have no problem in maintaining a separate
>> branch.

> Can you split the work into two patch series:
> 1. Target-independent TCG events (e.g. vbbl_begin)
> 2. "custom" trace backend that links custom C trace event handler
>    functions - but without dynamic libraries or stable API.

> It loses the dynamic library and stable API features but would be easy
> to merge.

Yes, I was thinking about sending a mail along those lines too. This basically
entails two series (2nd and 4th in my current branch):

* Support for tracing events at TCG code generation time (basically
  auto-generating per-event TCG helpers - trace_<event>_tcg -, which call the
  actual tracing event - trace_<event> -).

* The events themselves (calls to trace_<event>_tcg).

I can then maintain instrumentation support and its public API on a separate

Still, I'm not sure when I'll have time for this, as it will require moving a
few patches among the series I have now (and readjusting their contents).


 "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

reply via email to

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