From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MH31d-0006Xf-Di for qemu-devel@nongnu.org; Wed, 17 Jun 2009 17:50:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MH31Y-0006Sm-RU for qemu-devel@nongnu.org; Wed, 17 Jun 2009 17:50:32 -0400 Received: from [199.232.76.173] (port=36779 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MH31Y-0006S4-J2 for qemu-devel@nongnu.org; Wed, 17 Jun 2009 17:50:28 -0400 Received: from cheetah.cs.fiu.edu ([131.94.130.107]:55619) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MH31V-0005Au-PG for qemu-devel@nongnu.org; Wed, 17 Jun 2009 17:50:26 -0400 Received: from meg.local (unknown [76.74.149.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cheetah.cs.fiu.edu (Postfix) with ESMTP id CDCE3B882E3 for ; Wed, 17 Jun 2009 17:50:22 -0400 (EDT) Date: Wed, 17 Jun 2009 17:50:18 -0400 From: Luis Useche Message-ID: <20090617215018.GA32029@meg.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] Memory Traces for System Simulation List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi Guys, I have been trying the last two days to find the correct places in the qemu code to trace the memory accesses in the running system. The qemu code is somewhat confusing and there are plenty of places that look like the correct trace point. I know that there exist plenty of threads about this matter in the list but non of them solve my problem. Some people suggested to use Argos (http://www.few.vu.nl/argos/) to get this information. There are two problems with this: (1) There is no clear documentation on how to do this in Argos (2) The code seems outdated and does not compile in systems with gcc>=4. There is also a patch for qemu 0.8 but it does not apply anymore. http://www.csl.cornell.edu/~vince/projects/qemu-trace/old/. At the moment, I am instrumenting several functions in exec.c as my trace points: ldl_phys ldq_phys ldup_phys lduw_phys stl_phys_notdirty stq_phys_notdirty stl_phys stb_phys stw_phys stq_phys I would really appreciate any suggestion you have in order to solve my problem. If you have any insights in the solutions I explained above I would be very thankful. Given that many people seems to be having the same problem than I, it would be nice to have an actual framework that add this functionality to qemu. I can offer myself to do that as long as I have enough help. As a parallel question: Does qemu simulate CPU cache? i.e. There is always memory access even when this would not happen in a real system due to CPU cache? Thanks in advance, -- Luis Useche Ph.D. Student Florida International University