Re: [Qemu-devel] memory trace with qemu

[malc <av1474@comtv.ru>]

On Mon, 26 Jul 2010, Eliot Moss wrote:

> On 7/26/2010 6:20 AM, Llu?s 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.
> 
> Etc.
> 
> In the context of another simulator, we developed a different
> technique, which would be quite general and might be of interest
> for QEMU.  We communicate with the simulator via a "fake" *device*,
> mapped into user-mode memory using an mmap call.  If someone
> devised and coded such a device, then it could be used from any
> guest.

I'v done something similar a while ago:
http://repo.or.cz/w/qemu/malc.git/shortlog/refs/heads/wctpci

-- 
mailto:av1474@comtv.ru