Re: [Qemu-devel] memory trace with qemu

[Yufei Chen]

On Mon, Jul 26, 2010 at 6:20 PM, Lluís <address@hidden> wrote:
> Eduardo Cruz writes:
>
>> Thanks for your awnsers. Stean, after I find the right place to capture the
>> reads and writes I'll definitely try your trace tool.
>
>> Until now, this is what i found:
>
>> I am using the x86-64 target, and I know that, for instance, lots of reads
>> pass here:
>
>> target-i386/translate.c   gen_op_ld_T1_A0()
>
> Ok, I've seen at least 3 people working on this lately.
>
> Some time ago I wrote a message proposing two sets of modifications for qemu, 
> in
> order to allow the analysis of guest code (like feeding traces to an
> architecture simulator).
>
> What I proposed is based on two different functionalities:
>
> 1) backdoor: a mechanism for the guest to communicate with qemu, such that
>   tracing can be started, stopped, etc.
>
>   My current approach is to decode an instruction that is deemed invalid by 
> the
>   target ISA according to the manual.
>
>   This is only implemented for x86 right now, but it is trivial to implement 
> on
>   other architectures as long as there are unused opcodes.
>
> 2) instrumentation: a set of generic macros that signal events that might be 
> of
>   interest.
>
>   The idea is to have the very same macros on all targets, such that the user
>   can just define what to do when these are called (like using the qemu 
> tracing
>   mechanism), without bothering about the target architecture.
>
>   These include memory accesses, instruction fetch information (address, size,
>   used registers, defined registers and a generic opcode type), etc.
>   I started implementing it for x86, but the ISA is a hellish nightmare (no
>   news), and got sidetracked by other pending work.
>
>   The main idea is that instrumentation can be dynamically and selectively
>   activated/deactivated (thus the backdoor mechanism), and it is generated as
>   extra TCG code when active.

This is also what we are working on recently. We want to combine this
two functionalities to provide "smart watch pointer".

For example, the user can specify what memory location to be watched
(using backdoor). When the memory is accessed, it will trigger a
function in the underlying qemu to be called (using instrumentation).
With this mechanism, we can record memory access interleaving, guest
back trace and maybe other information that maybe useful for debugging
or other purposes.

>
> My intent was to spin up some discussion on which macros to provide, as well 
> as
> the most performant mechanism for for the dynamic (de)activation of these.
>
> So, the question is, again, if the qemu community is willing to provide this, 
> or
> should we maintain it as a separate set of patches.
>
> As I told Jun Koi, I'll try to set up a git repository at work for others to
> have access to the modifications and discuss the alternatives.
>
>
> Oh! BTW, my current prototype uses code like this on target-x86/translate.c:
>
>    #define tcg_gen_qemu_ld8u(arg, addr, mem_index)          \
>        do {                                                 \
>            INSTR_MEM(addr, 8);                              \
>            (tcg_gen_qemu_ld8u)(arg, addr, mem_index);       \
>        } while (0)
>
> Of course, this doesn't take into account DMA memory accesses and accesses
> produced by helper code.
>
>
> Lluís
>
> --
>  "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
>



-- 
Best regards,
Chen Yufei