qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Benchmarking activities


From: Lluís
Subject: Re: [Qemu-devel] Benchmarking activities
Date: Mon, 04 Jul 2011 14:47:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Andreas Färber writes:

> Am 02.07.2011 um 10:32 schrieb Stefan Hajnoczi:
>> On Fri, Jul 1, 2011 at 8:32 PM, Blue Swirl <address@hidden> wrote:
>>> 2011/6/27 Ben Vogler <address@hidden>:
>>>> -           Are there any inbuilt data tracing features? For example,
>>>> hardware signal tracing, register monitoring etc.
>>> 
>>> Tracing is quite new addition, so far it's only used for development
>>> or debugging QEMU point of view I think.
>> 
>> I think you are referring to hardware model debugging and logging.
>> The QEMU "tracing" mechanism that Blue Swirl mentioned is a
>> DTrace/SystemTap style tool for observing QEMU internals and not what
>> you are looking for.

> I believe Lluís (cc'ed) has worked on using/extending the trace framework to
> instrument guests.

Yes, the idea is to have a set of generic guest events (e.g.,
information during instruction fetch, privilege-level change, control
flow instructions, etc.) that are target agnostic.

This is coupled with the possibility to statically instrument tracing
points with user-provided code, so that almost anything can be done with
these few basic pieces, ranging from code instrumentation tools a-la
PIN, information flow tracking analysis or even cycle-accurate
simulations driven by QEMU as the target emulation component. All with a
target-agnostic interface that is common to both system-wide and user
application functional simulation.

I've also modified the timing infrasructure to have a more accurate
guest cycle counter that is able to handle a per-vCPU CPI (cycles per
instruction), as the current approach in QEMU is not adecuate for
cycle-accurate simulations.

I've been developing all these changes in small self-contained patches,
as my intention is to work towards having these generic pieces
integrated into QEMU proper, so that everybody can benefit from that
work, as well as avoid having a separate project that will otherwise
quickly fall behind QEMU's codebase.

What I still haven't decided is whether this generic interface should
provide the user with a way to modify the behaviour of the guest, like
skipping the execution of QEMU-generated code and instead execute
user-provided code to change the semantics of certain instructions
without having to hack directly into QEMU.


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]