qemu-devel
[Top][All Lists]
Advanced

[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: Sun, 28 Apr 2013 21:25:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Stefan Hajnoczi writes:

> 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.

Yes, my assumption was that the library is invoked on the vCPU's thread, so
everything is performed on its context. For other non-guest tracing events, you
need to know what's going on in QEMU, and that's why events are not
instrumentable by default.

What I didn't yet get to implement is to safely unload an instrumentation
library or change the callback for an event (e.g., ensure it is performed
exclusively).

As for the heterogeneous case, I thought it was still far, so I didn't give it
much thought. Most of the code in the base infrastructure is oblivious to the
target. Once you need that, the affected target-specific routines would need to
be defined using something similar to the current function pointers in CPUState
when having a heterogeneous QEMU.


>> 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.

Ok, my bad. After the initial discussions that took place long ago I understood
there actually was some interest in having such functionality, although not with
all the public APIs I added.

I have no problem in maintaining a separate branch for certain events and
interfaces (some of which are currently quite crude and hackish in the final
series), as long as the bases are upstream (e.g., instrumentation
infrastructure, and the most basic abstract guest events).


> 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.

I'm not sure what you mean by such a tool. What some patches do is, for example,
call "trace_vbbl_begin" at the beginning of the main loop of
"gen_intermediate_code_internal" of each target. The user does not instrument
calls to actual TCG routines (which know near to nothing about the guest
semantics), but only the "vbbl_begin" event.

In fact, while looking at all the targets I thought about unifying code by
merging code generation of all targets using a single common header implementing
the main loop, with callbacks to target-specific code. But I thought that would
be too invasive to the project.

I agree that all the public API could become a burden for a project only
interested in functional emulation and virtualization, but as I said I think the
most basic parts of it could be landed, already providing a powerful
infrastructure where further extension is up to the user.


> 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.


Thanks,
  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



reply via email to

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