From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=33262 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OdLNM-0007l9-EM
	for qemu-devel@nongnu.org; Mon, 26 Jul 2010 06:57:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <moss@cs.umass.edu>) id 1OdLNF-0003vm-OI
	for qemu-devel@nongnu.org; Mon, 26 Jul 2010 06:57:38 -0400
Received: from csmail.cs.umass.edu ([128.119.240.177]:54385)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <moss@cs.umass.edu>) id 1OdLNF-0003vh-Mp
	for qemu-devel@nongnu.org; Mon, 26 Jul 2010 06:57:33 -0400
Message-ID: <4C4D6A1C.1020004@cs.umass.edu>
Date: Mon, 26 Jul 2010 06:57:32 -0400
From: Eliot Moss <moss@cs.umass.edu>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] memory trace with qemu
References: <AANLkTinMquF1oXgDg5fyKNF1Rxcz2_vMSvJmyH7E46bi@mail.gmail.com>	<AANLkTimyuF6ZNaWXar2qYwC_tl4pclCu136dH8wpa9xM@mail.gmail.com>	<AANLkTili9UdnzkpKh-YBhARzI-1NWewuvf1b3pH-5Zd9@mail.gmail.com>	<AANLkTinTD4hSj_Yqa8rSdS_OZGLsxq4dZY_C+vypd1vS@mail.gmail.com>	<AANLkTinQUoxNfnWJTAD6Ou13QVG5H2SoGYWMb4czJx=o@mail.gmail.com>	<AANLkTimE+p9s=mge2+dSUJcVajFV3xkd0SKt9v+X4yiu@mail.gmail.com>
	<86ocdua6jq.wl%lluis@ginnungagap.pc.ac.upc.edu>
In-Reply-To: <86ocdua6jq.wl%lluis@ginnungagap.pc.ac.upc.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Reply-To: moss@cs.umass.edu
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?UTF-8?B?TGx1w61z?= <xscript@gmx.net>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, Yufei Chen <cyfdecyf@gmail.com>, Mulyadi Santosa <mulyadi.santosa@gmail.com>, qemu-devel@nongnu.org, Eduardo Cruz <eduardohmdacruz@gmail.com>

On 7/26/2010 6:20 AM, Llu=C3=ADs wrote:
> Eduardo Cruz writes:
>
>> Thanks for your awnsers. Stean, after I find the right place to captur=
e 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 r=
eads
>> 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 t=
hat
>     tracing can be started, stopped, etc.
>
>     My current approach is to decode an instruction that is deemed inva=
lid by the
>     target ISA according to the manual.
>
>     This is only implemented for x86 right now, but it is trivial to im=
plement on
>     other architectures as long as there are unused opcodes.
>
> 2) instrumentation: a set of generic macros that signal events that mig=
ht 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.

Regards -- Eliot Moss