Re: [Qemu-devel] memory trace with qemu

[Lluís]

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.

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