Re: [Qemu-devel] memory trace with qemu

[Eduardo Cruz]

In the modification:
 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)

As far as I understand, at this point, the code is still beig
translated, so we still dont know at this point the virtual address,
because the address will be computed when the generated code executes.
Am I correct? or am I completely lost?

I think qemu should support the memory trace, and I'll try to do it.
I've already managed to hack the linux kernel to make it easy to
obtain the pid of the current process running on the cpu. If we can
make qemu generate the trace, we can make it only record the memory
access of specific process. I already do this using simics, but it is
extremely slow.

2010/7/26 Yufei Chen <address@hidden>
>
> 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



--
Eduardo Henrique Molina da Cruz
MSc student
Parallel and Distributed Processing Group
Federal University of Rio Grande do Sul (UFRGS)