On Fri, Apr 26, 2013 at 02:15:46PM +0200, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
>
> > On Wed, Apr 24, 2013 at 02:17:22PM +0200, Lluís Vilanova wrote:
> > 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.
They would be affected by things like real TCG vcpu threads (parallel
translation and execution) because now trace events will be invoked
simultaneously from multiple threads. Or heterogenous cores in QEMU
(ARM + DSP) where previously you could assume there is one target
architecture.
> 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).
I don't think this effort is maintainable.
The API would be great if QEMU was heavily focussed on instrumentation
and simulation research. It allows interesting analysis without diving
into the internals of QEMU.
The problem is it touches everything in QEMU because you should be able
to instrument everything. Who is going to maintain an API of this
scope?
The QEMU community has two large groups: TCG for emulation and KVM for
virtualization. The API doesn't offer them anything so they will not
keep it in mind when making changes.
This is why I think it makes more sense to focus on specific tools that
don't try to introduce stable APIs. i.e. a tool for instruction tracing
in TCG.
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).
Stefan
