From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agdVh-0001QK-Vm for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:23:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agdVe-0008WI-Q6 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:23:05 -0400 Received: from roura.ac.upc.edu ([147.83.33.10]:60859 helo=roura.ac.upc.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agdVe-0008W1-Dy for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:23:02 -0400 From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= References: <145625172744.12025.2350972792125742783.stgit@localhost> <145625173880.12025.6630606700468410319.stgit@localhost> Date: Thu, 17 Mar 2016 20:22:52 +0100 In-Reply-To: (Peter Maydell's message of "Wed, 16 Mar 2016 15:01:09 +0000") Message-ID: <8737rorjsj.fsf@fimbulvetr.bsc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/5] trace: [all] Add "guest_vmem" event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Richard Henderson , QEMU Developers , Stefan Hajnoczi , Peter Crosthwaite Peter Maydell writes: > On 23 February 2016 at 18:22, Llu=C3=ADs Vilanova w= rote: >> Signed-off-by: Llu=C3=ADs Vilanova >> +### Guest events, keep at bottom >> + >> +# @vaddr: Access' virtual address. >> +# @size : Access' size (bytes). >> +# @store: Whether the access is a store. >> +# >> +# Start virtual memory access (before any potential access violation). >> +# >> +# Does not include memory accesses performed by devices. >> +# >> +# Targets: TCG(all) >> +disable vcpu tcg guest_vmem(TCGv vaddr, uint8_t size, uint8_t store) "s= ize=3D%d store=3D%d", "vaddr=3D0x%016"PRIx64" size=3D%d store=3D%d" > Shouldn't we also be tracing some of the other information in the memop? > In particular, endianness of the access seems useful. You could also > say whether we're zero- or sign-extending the access, though I guess > you could defend not printing that since we don't print anything about > what the target- code does with the loaded data. > Otherwise I think this looks OK (though the various paths memory accesses > take are a bit opaque since I've forgotten how this bit of QEMU works). Mmmmm, the endianness seems more of a vCPU property than one of the memory access. A separate event could be added for that (e.g., at vCPU initalization/hot-plug and whenever it is dynamically changed like in ARM). For the sign extension and memory value, what about adding multiple events? What I did for instructions is have a simple event and one with extended information, so that we can tweak performance of a tracing QEMU by choosing= one or the other. We could do the same for memory accesses (e.g., also show the memory value, sign extension and physical address).