qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Register usage statistics?


From: Lluís
Subject: Re: [Qemu-devel] Register usage statistics?
Date: Fri, 26 Aug 2011 20:48:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Peter Maydell writes:

> On 26 August 2011 18:35, Lluís <address@hidden> wrote:
>> Benjamin Ylvisaker writes:
>>> I am working on a project for which I'd like to gather statistics
>>> about register usage.  (For example, distributions of degree-of-use
>>> and dynamic lifetimes of register-values.)  Is QEMU a good tool for
>>> doing this kind of work?  Has anyone else done this?  I looked at the
>>> tracing available in QEMU and it seems to be mostly for higher level
>>> things like memory accesses, function calls, basic block executions,
>>> etc.
>> 
>> This is not currently possible.
>> 
>> In fact, I've been developing (somewhat in the background) the kind of
>> features you're asking for, but it will still be at least a couple of
>> months before it's in a publishable state.

> Interesting. I know the folks at STM have also done work in this
> area (see the QEMU Users Forum talk they did about dynamic tracing).
> Would you mind giving a quick summary of the sort of approach you've
> taken? I'm wondering if there's much overlap or if you and they are
> really addressing different problems.

Hmmm, I didn't know about that piece of work; I'll look into that. My
approach is basically on the lines of previous RFCs I sent to this list.

On one hand, some architecture-agnostic guest-code events can be traced
at the TCG level, using QEMU's tracing infrastructure (i.e., instruction
"fetch", virtual memory access, interrupts, exceptions, etc.). The set
of events is not yet complete, as right now it's just a prototype, but
it can be easily expanded over time.

This is coupled together with the ability to instrument any tracing
event with user-provided code. The RFC I sent long ago was based on a
much hackier version that used preprocessor macros.

My ideal is to work on having all these changes accepted into upstream,
as their invasiveness right now is moderately low and by default adds no
overhead.

On top of that, I have a QEMU trace instrumentation library that does
all the heavy lifting in order to generate extra tcg code to let the
user track only the portions of guest-code and the types of events she
is interested in. Of course, the source code of this library will also
be open to the public (which is what I'm working on right now).

The ultimate goal is to provide an environment that eases the
development of architecture-agnostic guest-code analyzers with QEMU
(with all its advantages on multi-target support and portability), so
that the user can concentrate on the analyzes themselves.


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]