From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3hHh-0005w4-Od for qemu-devel@nongnu.org; Tue, 21 Aug 2012 01:45:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3hHg-0006AC-0Y for qemu-devel@nongnu.org; Tue, 21 Aug 2012 01:45:49 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:64813) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3hHf-0006A6-G7 for qemu-devel@nongnu.org; Tue, 21 Aug 2012 01:45:47 -0400 Received: by iakx26 with SMTP id x26so3044111iak.4 for ; Mon, 20 Aug 2012 22:45:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20120816080243.GA33123@cs.nctu.edu.tw> <20120817111436.GB67669@cs.nctu.edu.tw> Date: Tue, 21 Aug 2012 01:40:07 -0400 Message-ID: From: Steven Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] qemu log function to print out the registers of the guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Filippov Cc: Laurent Desnogues , qemu-devel@nongnu.org, =?UTF-8?B?6Zmz6Z+L5Lu7IChXZWktUmVuIENoZW4p?= Hi, Max, I wrote a small program to verify your patch could catch all the load instructions from the guest. However, I found some problem from the results. The guest OS and the emulated machine are both 32bit x86. My simple program in the guest declares an 1048576-element integer array, initialize the elements, and load them in a loop. It looks like this int array[1048576]; initialize the array; /* region of interests */ int temp; for (i=3D0; i < 1048576; i++) { temp =3D array[i]; } So ideally, the path should catch the guest virtual address of in the loop, right? In addition, the virtual address for the beginning and end of the array is 0xbf68b6e0 and 0xbfa8b6e0. What i got is as follows __ldl_mmu, vaddr=3Dbf68b6e0 __ldl_mmu, vaddr=3Dbf68b6e4 __ldl_mmu, vaddr=3Dbf68b6e8 ..... These should be the virtual address of the above loop. The results look good because the gap between each vaddr is 4 bypte, which is the length of each element. However, after certain address, I got __ldl_mmu, vaddr=3Dbf68bffc __ldl_mmu, vaddr=3Dbf68c000 __ldl_mmu, vaddr=3Dbf68d000 __ldl_mmu, vaddr=3Dbf68e000 __ldl_mmu, vaddr=3Dbf68f000 __ldl_mmu, vaddr=3Dbf690000 __ldl_mmu, vaddr=3Dbf691000 __ldl_mmu, vaddr=3Dbf692000 __ldl_mmu, vaddr=3Dbf693000 __ldl_mmu, vaddr=3Dbf694000 ... __ldl_mmu, vaddr=3Dbf727000 __ldl_mmu, vaddr=3Dbf728000 __ldl_mmu, vaddr=3Dbfa89000 __ldl_mmu, vaddr=3Dbfa8a000 So the rest of the vaddr I got has a different of 4096 bytes, instead of 4. I repeated the experiment for several times and got the same results. Is there anything wrong? or could you explain this? Thanks. steven On Fri, Aug 17, 2012 at 7:57 AM, Max Filippov wrote: > On Fri, Aug 17, 2012 at 3:14 PM, =E9=99=B3=E9=9F=8B=E4=BB=BB (Wei-Ren Che= n) > wrote: >>> > On Thu, Aug 16, 2012 at 7:49 PM, Steven wrot= e: >>> > [...] >>> >> I want to get the guest memory address in the instruction mov >>> >> 0x4(%ebx) %eax, whic is 0x4(%ebx). >>> >> Since %ebx is not resolved until the execution time, the code in >>> >> softmmu_header.h does not generate any hit or miss information. >>> >> Do you know any place that I could resolve the memory access address= ? Thanks. >>> > >>> > You'll have to generate code. Look at how helpers work. >>> Hi, Laurent, >>> do you mean the target-i386/op_helper.c/helper.c or the tcg helper? Tha= nks. >> >> What do you mean by "resolve the memory access address"? Do you want >> to get guest virtual address for each guest memory access, right? As Max >> mentioned before (you can also read [1]), there are fast and slow path >> in QEMU softmmu, tlb hit and tlb miss respectively. Max provided patch >> for slow path. As for fast path, take a look on tcg_out_tlb_load (tcg >> /i386/tcg-target.c). tcg_out_tlb_load will generate native code in the >> code cache to do tlb lookup, I think you cannot use the trick Max used >> since tcg_out_tlb_load will not be called when the fast path executed, > > That's why I've posted the following hunk that should have made all > accesses go via slow path: > > diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c > index da17bba..ec68c19 100644 > --- a/tcg/i386/tcg-target.c > +++ b/tcg/i386/tcg-target.c > @@ -1062,7 +1062,7 @@ static inline void tcg_out_tlb_load(TCGContext > *s, int addrlo_idx, > tcg_out_mov(s, type, r0, addrlo); > > /* jne label1 */ > - tcg_out8(s, OPC_JCC_short + JCC_JNE); > + tcg_out8(s, OPC_JMP_short); > label_ptr[0] =3D s->code_ptr; > s->code_ptr++; > > >> it "generates" code instead. Therefore, you might have to insert your >> instrument code in the code cache, perhaps modifying tcg_out_tlb_load >> to log value of "addrlo" (see comments above tcg_out_tlb_load). > > -- > Thanks. > -- Max