Re: [Qemu-devel] qemu log function to print out the registers of the guest

[Steven]

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=0; i < 1048576; i++) {
              temp = 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=bf68b6e0
          __ldl_mmu, vaddr=bf68b6e4
          __ldl_mmu, vaddr=bf68b6e8
          .....
          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=bf68bffc
          __ldl_mmu, vaddr=bf68c000
          __ldl_mmu, vaddr=bf68d000
          __ldl_mmu, vaddr=bf68e000
          __ldl_mmu, vaddr=bf68f000
          __ldl_mmu, vaddr=bf690000
          __ldl_mmu, vaddr=bf691000
          __ldl_mmu, vaddr=bf692000
          __ldl_mmu, vaddr=bf693000
          __ldl_mmu, vaddr=bf694000
          ...
          __ldl_mmu, vaddr=bf727000
          __ldl_mmu, vaddr=bf728000
          __ldl_mmu, vaddr=bfa89000
          __ldl_mmu, vaddr=bfa8a000
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 <address@hidden> wrote:
> On Fri, Aug 17, 2012 at 3:14 PM, 陳韋任 (Wei-Ren Chen)
> <address@hidden> wrote:
>>> > On Thu, Aug 16, 2012 at 7:49 PM, Steven <address@hidden> wrote:
>>> > [...]
>>> >> 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? Thanks.
>>
>>   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] = 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