[Top][All Lists]
[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