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

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

[Steven]

Hi,
I would like to is there any function that could log the register
content of the guest machine, like "info registers" in the qemu
monitor mode.
Thanks.

steven

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

[陳韋任 (Wei-Ren Chen)]

> I would like to is there any function that could log the register
> content of the guest machine, like "info registers" in the qemu
> monitor mode.

  Why not check how "info registes" be implemented in QEMU? ;)
I guess you just have to log env->regs or something like that.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

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

[Steven]

On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
<chenwj@iis.sinica.edu.tw> wrote:
>> I would like to is there any function that could log the register
>> content of the guest machine, like "info registers" in the qemu
>> monitor mode.
>
>   Why not check how "info registes" be implemented in QEMU? ;)
> I guess you just have to log env->regs or something like that.
Thanks for pointing this out.
I would like to get a trace of guest memory access. So I can not use
"info registers".
What I want to do is that when tcg fetches a load instruction at
disas_insns(), the guest memory address should be calculated. For
example, the tb has an instruction of mov 0x4(%ebx)  %eax.
To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
Is this correct? Thanks.

>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Computer Systems Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
> Homepage: http://people.cs.nctu.edu.tw/~chenwj

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

[Peter Maydell]

On 16 August 2012 17:36, Steven <wangwangkang@gmail.com> wrote:
> I would like to get a trace of guest memory access. So I can not use
> "info registers".
> What I want to do is that when tcg fetches a load instruction at
> disas_insns(), the guest memory address should be calculated.

You cannot calculate the guest memory address at the point where
TCG is translating the load instruction. This is because that
address depends on the values of guest registers at runtime.
At translation time these values are not known. Also they may
be different for different runs through the same generated code.

QEMU is a just-in-time translator (JIT). For a JIT it is
important to remember the difference between:
 * translation time. Here we know what the guest code (instructions)
are, but we do not know what the guest CPU registers will be
 * run time. This may be some time later, and we may execute
the same code several times. We don't have any access to
information about the guest code we are running unless
we specifically recorded it at translation time.

When you are reading (or trying to change) QEMU source code
you need to know whether the QEMU code will be running at
translation or run time. The answer affects what information
you have access to, and what you can do to the guest.

-- PMM

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

[Steven]

On Thu, Aug 16, 2012 at 12:54 PM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 16 August 2012 17:36, Steven <wangwangkang@gmail.com> wrote:
>> I would like to get a trace of guest memory access. So I can not use
>> "info registers".
>> What I want to do is that when tcg fetches a load instruction at
>> disas_insns(), the guest memory address should be calculated.
>
> You cannot calculate the guest memory address at the point where
> TCG is translating the load instruction. This is because that
> address depends on the values of guest registers at runtime.
> At translation time these values are not known. Also they may
> be different for different runs through the same generated code.

Thanks. Then what I thought is wrong.

>
> QEMU is a just-in-time translator (JIT). For a JIT it is
> important to remember the difference between:
>  * translation time. Here we know what the guest code (instructions)
> are, but we do not know what the guest CPU registers will be
>  * run time. This may be some time later, and we may execute
> the same code several times. We don't have any access to
> information about the guest code we are running unless
> we specifically recorded it at translation time.

Take this in_asm as example, mov 0x4(%ebx)  %eax. I saw the translated
host code for this single load instruction (using -d in_asm,out_asm)
are

OUT: [size=107]
0x4025d890:  mov    0x28(%r14),%rbp
0x4025d894:  add    $0xc,%rbp
0x4025d898:  mov    %ebp,%ebp
...
0x4025d8e8:  mov    %rbp,0x8(%r14)
0x4025d8ec:  xor    %eax,%eax
0x4025d8ee:  mov    $0x7fc1a598d176,%r10
0x4025d8f8:  jmpq   *%r10
So the run time function should be tcg_out_qemu_ld, right?
Could you provide some suggestion where I should add the record
information to help translate the guest memory address? Thanks.


>
> When you are reading (or trying to change) QEMU source code
> you need to know whether the QEMU code will be running at
> translation or run time. The answer affects what information
> you have access to, and what you can do to the guest.
>
> -- PMM

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

[Peter Maydell]

On 16 August 2012 18:13, Steven <wangwangkang@gmail.com> wrote:
> So the run time function should be tcg_out_qemu_ld, right?

No, tcg_out_qemu_ld is a translate time function, which emits
the native (x86 in this case) instructions necessary to perform
a guest load.

-- PMM

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

[Steven]

On Thu, Aug 16, 2012 at 1:15 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 16 August 2012 18:13, Steven <wangwangkang@gmail.com> wrote:
>> So the run time function should be tcg_out_qemu_ld, right?
>
> No, tcg_out_qemu_ld is a translate time function, which emits
> the native (x86 in this case) instructions necessary to perform
> a guest load.

Could you help to point out which part of qemu shall I trap to examine
the content of the guest load instruction? Thanks.


>
> -- PMM

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

[Steven]

On Thu, Aug 16, 2012 at 12:54 PM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 16 August 2012 17:36, Steven <wangwangkang@gmail.com> wrote:
>> I would like to get a trace of guest memory access. So I can not use
>> "info registers".
>> What I want to do is that when tcg fetches a load instruction at
>> disas_insns(), the guest memory address should be calculated.
>
> You cannot calculate the guest memory address at the point where
> TCG is translating the load instruction. This is because that
> address depends on the values of guest registers at runtime.
> At translation time these values are not known. Also they may
> be different for different runs through the same generated code.
>
> QEMU is a just-in-time translator (JIT). For a JIT it is
> important to remember the difference between:
>  * translation time. Here we know what the guest code (instructions)
> are, but we do not know what the guest CPU registers will be
>  * run time. This may be some time later, and we may execute
> the same code several times. We don't have any access to
> information about the guest code we are running unless
> we specifically recorded it at translation time.

To verify what is translation time and what is the run time, I log the
register information before disassembling each guest code. I copied
some results from the log file, which is generated at run time of a
guest machine.

         EAX=00000000  EBX=00006ffc
         IN:
         0x00000000000f2087:  mov    $0xf5588,%eax

         EAX=000f5588  EBX=00006ffc
         IN:
         0x00000000000f208B:  move 0x4(%ebx)  %eax

The first instruction load eax with the value 0xf5588, so the eax at
the second instruction is EAX=000f5588. So can I consider the memory
address of 0x4(%ebx) as (00006ffc +  4)? I think this should be the
run time information I need. Please correct me  if there is anything
wrong. Thanks.

>
> When you are reading (or trying to change) QEMU source code
> you need to know whether the QEMU code will be running at
> translation or run time. The answer affects what information
> you have access to, and what you can do to the guest.
>
> -- PMM

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

[陳韋任 (Wei-Ren Chen)]

> To verify what is translation time and what is the run time, I log the
> register information before disassembling each guest code. I copied
> some results from the log file, which is generated at run time of a
> guest machine.
> 
>          EAX=00000000  EBX=00006ffc
>          IN:
>          0x00000000000f2087:  mov    $0xf5588,%eax
> 
>          EAX=000f5588  EBX=00006ffc
>          IN:
>          0x00000000000f208B:  move 0x4(%ebx)  %eax
> 
> The first instruction load eax with the value 0xf5588, so the eax at
> the second instruction is EAX=000f5588. So can I consider the memory
> address of 0x4(%ebx) as (00006ffc +  4)? I think this should be the
> run time information I need. Please correct me  if there is anything
> wrong. Thanks.

  IIRC, "-d in_asm" only give you what has been translated not executed.
Remember you said you log the register information before disassembling
each guest code? In other words, (guest) ebx might not be the value you
saw here. This is just my opinion.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

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

[Max Filippov]

On Thu, Aug 16, 2012 at 8:36 PM, Steven <wangwangkang@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
> <chenwj@iis.sinica.edu.tw> wrote:
>>> I would like to is there any function that could log the register
>>> content of the guest machine, like "info registers" in the qemu
>>> monitor mode.
>>
>>   Why not check how "info registes" be implemented in QEMU? ;)
>> I guess you just have to log env->regs or something like that.
> Thanks for pointing this out.
> I would like to get a trace of guest memory access. So I can not use
> "info registers".
> What I want to do is that when tcg fetches a load instruction at
> disas_insns(), the guest memory address should be calculated. For

No, you don't want this, because the same translated code may be
invoked multiple times with different values in registers.

> example, the tb has an instruction of mov 0x4(%ebx)  %eax.
> To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
> Is this correct? Thanks.

Why don't you just instrument actual memory access functions in
softmmu_template.h ?

-- 
Thanks.
-- Max

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

[Steven]

On Thu, Aug 16, 2012 at 1:00 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 8:36 PM, Steven <wangwangkang@gmail.com> wrote:
>> On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
>> <chenwj@iis.sinica.edu.tw> wrote:
>>>> I would like to is there any function that could log the register
>>>> content of the guest machine, like "info registers" in the qemu
>>>> monitor mode.
>>>
>>>   Why not check how "info registes" be implemented in QEMU? ;)
>>> I guess you just have to log env->regs or something like that.
>> Thanks for pointing this out.
>> I would like to get a trace of guest memory access. So I can not use
>> "info registers".
>> What I want to do is that when tcg fetches a load instruction at
>> disas_insns(), the guest memory address should be calculated. For
>
> No, you don't want this, because the same translated code may be
> invoked multiple times with different values in registers.
>
>> example, the tb has an instruction of mov 0x4(%ebx)  %eax.
>> To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
>> Is this correct? Thanks.
>
> Why don't you just instrument actual memory access functions in
> softmmu_template.h ?
But this code only touches the s->pc. For registers in the load
instruction, it won't generate the memory access code. So I need to
add code to some function to get the guest memory address access.
>
> --
> Thanks.
> -- Max

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

[Max Filippov]

On Thu, Aug 16, 2012 at 9:29 PM, Steven <wangwangkang@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 1:00 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> On Thu, Aug 16, 2012 at 8:36 PM, Steven <wangwangkang@gmail.com> wrote:
>>> On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
>>> <chenwj@iis.sinica.edu.tw> wrote:
>>>>> I would like to is there any function that could log the register
>>>>> content of the guest machine, like "info registers" in the qemu
>>>>> monitor mode.
>>>>
>>>>   Why not check how "info registes" be implemented in QEMU? ;)
>>>> I guess you just have to log env->regs or something like that.
>>> Thanks for pointing this out.
>>> I would like to get a trace of guest memory access. So I can not use
>>> "info registers".
>>> What I want to do is that when tcg fetches a load instruction at
>>> disas_insns(), the guest memory address should be calculated. For
>>
>> No, you don't want this, because the same translated code may be
>> invoked multiple times with different values in registers.
>>
>>> example, the tb has an instruction of mov 0x4(%ebx)  %eax.
>>> To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
>>> Is this correct? Thanks.
>>
>> Why don't you just instrument actual memory access functions in
>> softmmu_template.h ?
> But this code only touches the s->pc. For registers in the load
> instruction, it won't generate the memory access code. So I need to
> add code to some function to get the guest memory address access.

Take a close look at

DATA_TYPE
glue(glue(glue(HELPER_PREFIX, ld), SUFFIX), MMUSUFFIX)(ENV_PARAM
                                                       target_ulong addr,
                                                       int mmu_idx)

and

void glue(glue(glue(HELPER_PREFIX, st), SUFFIX), MMUSUFFIX)(ENV_PARAM
                                                            target_ulong addr,
                                                            DATA_TYPE val,
                                                            int mmu_idx)

At runtime they get addr, this is the virtual address of the memory access.
This file is included several times to instantiate these functions for
different memory access types.
A set of macros manipulates access size and whether it is code or data access.

-- 
Thanks.
-- Max

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

[Max Filippov]

On Thu, Aug 16, 2012 at 9:37 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 9:29 PM, Steven <wangwangkang@gmail.com> wrote:
>> On Thu, Aug 16, 2012 at 1:00 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>> On Thu, Aug 16, 2012 at 8:36 PM, Steven <wangwangkang@gmail.com> wrote:
>>>> On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
>>>> <chenwj@iis.sinica.edu.tw> wrote:
>>>>>> I would like to is there any function that could log the register
>>>>>> content of the guest machine, like "info registers" in the qemu
>>>>>> monitor mode.
>>>>>
>>>>>   Why not check how "info registes" be implemented in QEMU? ;)
>>>>> I guess you just have to log env->regs or something like that.
>>>> Thanks for pointing this out.
>>>> I would like to get a trace of guest memory access. So I can not use
>>>> "info registers".
>>>> What I want to do is that when tcg fetches a load instruction at
>>>> disas_insns(), the guest memory address should be calculated. For
>>>
>>> No, you don't want this, because the same translated code may be
>>> invoked multiple times with different values in registers.
>>>
>>>> example, the tb has an instruction of mov 0x4(%ebx)  %eax.
>>>> To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
>>>> Is this correct? Thanks.
>>>
>>> Why don't you just instrument actual memory access functions in
>>> softmmu_template.h ?
>> But this code only touches the s->pc. For registers in the load
>> instruction, it won't generate the memory access code. So I need to
>> add code to some function to get the guest memory address access.
>
> Take a close look at
>
> DATA_TYPE
> glue(glue(glue(HELPER_PREFIX, ld), SUFFIX), MMUSUFFIX)(ENV_PARAM
>                                                        target_ulong addr,
>                                                        int mmu_idx)
>
> and
>
> void glue(glue(glue(HELPER_PREFIX, st), SUFFIX), MMUSUFFIX)(ENV_PARAM
>                                                             target_ulong addr,
>                                                             DATA_TYPE val,
>                                                             int mmu_idx)
>
> At runtime they get addr, this is the virtual address of the memory access.
> This file is included several times to instantiate these functions for
> different memory access types.
> A set of macros manipulates access size and whether it is code or data access.

But maybe I got you wrong and by

  What I want to do is that when tcg fetches a load instruction at
  disas_insns(), the guest memory address should be calculated.

you meant that you need to record code address that made an access,
not the accessed data address?

-- 
Thanks.
-- Max

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

[Steven]

On Thu, Aug 16, 2012 at 1:43 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 9:37 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> On Thu, Aug 16, 2012 at 9:29 PM, Steven <wangwangkang@gmail.com> wrote:
>>> On Thu, Aug 16, 2012 at 1:00 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>>> On Thu, Aug 16, 2012 at 8:36 PM, Steven <wangwangkang@gmail.com> wrote:
>>>>> On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
>>>>> <chenwj@iis.sinica.edu.tw> wrote:
>>>>>>> I would like to is there any function that could log the register
>>>>>>> content of the guest machine, like "info registers" in the qemu
>>>>>>> monitor mode.
>>>>>>
>>>>>>   Why not check how "info registes" be implemented in QEMU? ;)
>>>>>> I guess you just have to log env->regs or something like that.
>>>>> Thanks for pointing this out.
>>>>> I would like to get a trace of guest memory access. So I can not use
>>>>> "info registers".
>>>>> What I want to do is that when tcg fetches a load instruction at
>>>>> disas_insns(), the guest memory address should be calculated. For
>>>>
>>>> No, you don't want this, because the same translated code may be
>>>> invoked multiple times with different values in registers.
>>>>
>>>>> example, the tb has an instruction of mov 0x4(%ebx)  %eax.
>>>>> To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
>>>>> Is this correct? Thanks.
>>>>
>>>> Why don't you just instrument actual memory access functions in
>>>> softmmu_template.h ?
>>> But this code only touches the s->pc. For registers in the load
>>> instruction, it won't generate the memory access code. So I need to
>>> add code to some function to get the guest memory address access.
>>
>> Take a close look at
>>
>> DATA_TYPE
>> glue(glue(glue(HELPER_PREFIX, ld), SUFFIX), MMUSUFFIX)(ENV_PARAM
>>                                                        target_ulong addr,
>>                                                        int mmu_idx)
>>
>> and
>>
>> void glue(glue(glue(HELPER_PREFIX, st), SUFFIX), MMUSUFFIX)(ENV_PARAM
>>                                                             target_ulong addr,
>>                                                             DATA_TYPE val,
>>                                                             int mmu_idx)
>>
>> At runtime they get addr, this is the virtual address of the memory access.
>> This file is included several times to instantiate these functions for
>> different memory access types.
>> A set of macros manipulates access size and whether it is code or data access.
>
> But maybe I got you wrong and by
>
>   What I want to do is that when tcg fetches a load instruction at
>   disas_insns(), the guest memory address should be calculated.
>
> you meant that you need to record code address that made an access,
> not the accessed data address?
>
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.

> --
> Thanks.
> -- Max

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

[Max Filippov]

On Thu, Aug 16, 2012 at 9:49 PM, Steven <wangwangkang@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 1:43 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> On Thu, Aug 16, 2012 at 9:37 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>> On Thu, Aug 16, 2012 at 9:29 PM, Steven <wangwangkang@gmail.com> wrote:
>>>> On Thu, Aug 16, 2012 at 1:00 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>>>> On Thu, Aug 16, 2012 at 8:36 PM, Steven <wangwangkang@gmail.com> wrote:
>>>>>> On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
>>>>>> <chenwj@iis.sinica.edu.tw> wrote:
>>>>>>>> I would like to is there any function that could log the register
>>>>>>>> content of the guest machine, like "info registers" in the qemu
>>>>>>>> monitor mode.
>>>>>>>
>>>>>>>   Why not check how "info registes" be implemented in QEMU? ;)
>>>>>>> I guess you just have to log env->regs or something like that.
>>>>>> Thanks for pointing this out.
>>>>>> I would like to get a trace of guest memory access. So I can not use
>>>>>> "info registers".
>>>>>> What I want to do is that when tcg fetches a load instruction at
>>>>>> disas_insns(), the guest memory address should be calculated. For
>>>>>
>>>>> No, you don't want this, because the same translated code may be
>>>>> invoked multiple times with different values in registers.
>>>>>
>>>>>> example, the tb has an instruction of mov 0x4(%ebx)  %eax.
>>>>>> To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
>>>>>> Is this correct? Thanks.
>>>>>
>>>>> Why don't you just instrument actual memory access functions in
>>>>> softmmu_template.h ?
>>>> But this code only touches the s->pc. For registers in the load
>>>> instruction, it won't generate the memory access code. So I need to
>>>> add code to some function to get the guest memory address access.
>>>
>>> Take a close look at
>>>
>>> DATA_TYPE
>>> glue(glue(glue(HELPER_PREFIX, ld), SUFFIX), MMUSUFFIX)(ENV_PARAM
>>>                                                        target_ulong addr,
>>>                                                        int mmu_idx)
>>>
>>> and
>>>
>>> void glue(glue(glue(HELPER_PREFIX, st), SUFFIX), MMUSUFFIX)(ENV_PARAM
>>>                                                             target_ulong addr,
>>>                                                             DATA_TYPE val,
>>>                                                             int mmu_idx)
>>>
>>> At runtime they get addr, this is the virtual address of the memory access.
>>> This file is included several times to instantiate these functions for
>>> different memory access types.
>>> A set of macros manipulates access size and whether it is code or data access.
>>
>> But maybe I got you wrong and by
>>
>>   What I want to do is that when tcg fetches a load instruction at
>>   disas_insns(), the guest memory address should be calculated.
>>
>> you meant that you need to record code address that made an access,
>> not the accessed data address?
>>
> 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.

I see that with the following patch

diff --git a/softmmu_template.h b/softmmu_template.h
index b8bd700..2d02133 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
     target_phys_addr_t ioaddr;
     uintptr_t retaddr;

+    fprintf(stderr, "%s: %08x\n", __func__, addr);
     /* test if there is match for unaligned or IO access */
     /* XXX: could done more in memory macro in a non portable way */
     index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);

I get some memory accesses logged, but not all. That's due to fast
path in tcg_out_qemu_ld
in case there's TLB hit. I guess you can play with tcg_out_qemu_ld and
make it produce a call
to a helper function, like qemu_ld_helpers, that will print addresses
for all memory access
attempts.

-- 
Thanks.
-- Max

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

[Max Filippov]

On Thu, Aug 16, 2012 at 10:31 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 9:49 PM, Steven <wangwangkang@gmail.com> wrote:
>> On Thu, Aug 16, 2012 at 1:43 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>> On Thu, Aug 16, 2012 at 9:37 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>>> On Thu, Aug 16, 2012 at 9:29 PM, Steven <wangwangkang@gmail.com> wrote:
>>>>> On Thu, Aug 16, 2012 at 1:00 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>>>>> On Thu, Aug 16, 2012 at 8:36 PM, Steven <wangwangkang@gmail.com> wrote:
>>>>>>> On Thu, Aug 16, 2012 at 4:02 AM, 陳韋任 (Wei-Ren Chen)
>>>>>>> <chenwj@iis.sinica.edu.tw> wrote:
>>>>>>>>> I would like to is there any function that could log the register
>>>>>>>>> content of the guest machine, like "info registers" in the qemu
>>>>>>>>> monitor mode.
>>>>>>>>
>>>>>>>>   Why not check how "info registes" be implemented in QEMU? ;)
>>>>>>>> I guess you just have to log env->regs or something like that.
>>>>>>> Thanks for pointing this out.
>>>>>>> I would like to get a trace of guest memory access. So I can not use
>>>>>>> "info registers".
>>>>>>> What I want to do is that when tcg fetches a load instruction at
>>>>>>> disas_insns(), the guest memory address should be calculated. For
>>>>>>
>>>>>> No, you don't want this, because the same translated code may be
>>>>>> invoked multiple times with different values in registers.
>>>>>>
>>>>>>> example, the tb has an instruction of mov 0x4(%ebx)  %eax.
>>>>>>> To calculate the address of 0x4(%ebx), I need to know the value of %ebx.
>>>>>>> Is this correct? Thanks.
>>>>>>
>>>>>> Why don't you just instrument actual memory access functions in
>>>>>> softmmu_template.h ?
>>>>> But this code only touches the s->pc. For registers in the load
>>>>> instruction, it won't generate the memory access code. So I need to
>>>>> add code to some function to get the guest memory address access.
>>>>
>>>> Take a close look at
>>>>
>>>> DATA_TYPE
>>>> glue(glue(glue(HELPER_PREFIX, ld), SUFFIX), MMUSUFFIX)(ENV_PARAM
>>>>                                                        target_ulong addr,
>>>>                                                        int mmu_idx)
>>>>
>>>> and
>>>>
>>>> void glue(glue(glue(HELPER_PREFIX, st), SUFFIX), MMUSUFFIX)(ENV_PARAM
>>>>                                                             target_ulong addr,
>>>>                                                             DATA_TYPE val,
>>>>                                                             int mmu_idx)
>>>>
>>>> At runtime they get addr, this is the virtual address of the memory access.
>>>> This file is included several times to instantiate these functions for
>>>> different memory access types.
>>>> A set of macros manipulates access size and whether it is code or data access.
>>>
>>> But maybe I got you wrong and by
>>>
>>>   What I want to do is that when tcg fetches a load instruction at
>>>   disas_insns(), the guest memory address should be calculated.
>>>
>>> you meant that you need to record code address that made an access,
>>> not the accessed data address?
>>>
>> 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.
>
> I see that with the following patch
>
> diff --git a/softmmu_template.h b/softmmu_template.h
> index b8bd700..2d02133 100644
> --- a/softmmu_template.h
> +++ b/softmmu_template.h
> @@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
> MMUSUFFIX)(ENV_PARAM
>      target_phys_addr_t ioaddr;
>      uintptr_t retaddr;
>
> +    fprintf(stderr, "%s: %08x\n", __func__, addr);
>      /* test if there is match for unaligned or IO access */
>      /* XXX: could done more in memory macro in a non portable way */
>      index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
>
> I get some memory accesses logged, but not all. That's due to fast
> path in tcg_out_qemu_ld
> in case there's TLB hit. I guess you can play with tcg_out_qemu_ld and
> make it produce a call
> to a helper function, like qemu_ld_helpers, that will print addresses
> for all memory access
> attempts.

Easier solution would be to disable fast path and always go through
softmmu helpers, like this (specific for x86 host):

diff --git a/softmmu_template.h b/softmmu_template.h
index b8bd700..2d02133 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
     target_phys_addr_t ioaddr;
     uintptr_t retaddr;

+    fprintf(stderr, "%s: %08x\n", __func__, addr);
     /* test if there is match for unaligned or IO access */
     /* XXX: could done more in memory macro in a non portable way */
     index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
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++;


-- 
Thanks.
-- Max

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

[Steven]

Hi, Max,
I appreciate your help and got some results using your patch. But I
still have two questions as blow.

>> I see that with the following patch
>>
>> diff --git a/softmmu_template.h b/softmmu_template.h
>> index b8bd700..2d02133 100644
>> --- a/softmmu_template.h
>> +++ b/softmmu_template.h
>> @@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
>> MMUSUFFIX)(ENV_PARAM
>>      target_phys_addr_t ioaddr;
>>      uintptr_t retaddr;
>>
>> +    fprintf(stderr, "%s: %08x\n", __func__, addr);
>>      /* test if there is match for unaligned or IO access */
>>      /* XXX: could done more in memory macro in a non portable way */
>>      index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
>>
>> I get some memory accesses logged, but not all. That's due to fast
>> path in tcg_out_qemu_ld
>> in case there's TLB hit. I guess you can play with tcg_out_qemu_ld and
>> make it produce a call
>> to a helper function, like qemu_ld_helpers, that will print addresses
>> for all memory access
>> attempts.
>
> Easier solution would be to disable fast path and always go through
> softmmu helpers, like this (specific for x86 host):
>
> diff --git a/softmmu_template.h b/softmmu_template.h
> index b8bd700..2d02133 100644
> --- a/softmmu_template.h
> +++ b/softmmu_template.h
> @@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
> MMUSUFFIX)(ENV_PARAM
>      target_phys_addr_t ioaddr;
>      uintptr_t retaddr;
>
> +    fprintf(stderr, "%s: %08x\n", __func__, addr);
>      /* test if there is match for unaligned or IO access */
>      /* XXX: could done more in memory macro in a non portable way */
>      index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
> 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++;
>

IN:
0x00000000c13e3a33:  mov    0x8(%ebp),%ebx (guest code in the tb)
__ldl_mmu: c13a9fdc

So 0xc13a9fdc is the guest virtual memory address of 0x8(%ebp). Is this correct?

IN:
0x00000000c13e3a36:  mov    %eax,-0x10(%ebp)
However, for this instruction, no ldl_mmu is logged.
Does that mean the patch you provided does not cover this case?
Thanks.

>
> --
> Thanks.
> -- Max

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

[Max Filippov]

On Fri, Aug 17, 2012 at 9:38 AM, Steven <wangwangkang@gmail.com> wrote:
> Hi, Max,
> I appreciate your help and got some results using your patch. But I
> still have two questions as blow.
>
>>> I see that with the following patch
>>>
>>> diff --git a/softmmu_template.h b/softmmu_template.h
>>> index b8bd700..2d02133 100644
>>> --- a/softmmu_template.h
>>> +++ b/softmmu_template.h
>>> @@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
>>> MMUSUFFIX)(ENV_PARAM
>>>      target_phys_addr_t ioaddr;
>>>      uintptr_t retaddr;
>>>
>>> +    fprintf(stderr, "%s: %08x\n", __func__, addr);
>>>      /* test if there is match for unaligned or IO access */
>>>      /* XXX: could done more in memory macro in a non portable way */
>>>      index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
>>>
>>> I get some memory accesses logged, but not all. That's due to fast
>>> path in tcg_out_qemu_ld
>>> in case there's TLB hit. I guess you can play with tcg_out_qemu_ld and
>>> make it produce a call
>>> to a helper function, like qemu_ld_helpers, that will print addresses
>>> for all memory access
>>> attempts.
>>
>> Easier solution would be to disable fast path and always go through
>> softmmu helpers, like this (specific for x86 host):
>>
>> diff --git a/softmmu_template.h b/softmmu_template.h
>> index b8bd700..2d02133 100644
>> --- a/softmmu_template.h
>> +++ b/softmmu_template.h
>> @@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
>> MMUSUFFIX)(ENV_PARAM
>>      target_phys_addr_t ioaddr;
>>      uintptr_t retaddr;
>>
>> +    fprintf(stderr, "%s: %08x\n", __func__, addr);
>>      /* test if there is match for unaligned or IO access */
>>      /* XXX: could done more in memory macro in a non portable way */
>>      index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
>> 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++;
>>
>
> IN:
> 0x00000000c13e3a33:  mov    0x8(%ebp),%ebx (guest code in the tb)
> __ldl_mmu: c13a9fdc
>
> So 0xc13a9fdc is the guest virtual memory address of 0x8(%ebp). Is this correct?

Right.

> IN:
> 0x00000000c13e3a36:  mov    %eax,-0x10(%ebp)
> However, for this instruction, no ldl_mmu is logged.
> Does that mean the patch you provided does not cover this case?

Yes, this is not 'ld', it is 'st'; to see it too I guess you need this:

diff --git a/softmmu_template.h b/softmmu_template.h
index b8bd700..b2ae078 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -114,6 +114,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
     target_phys_addr_t ioaddr;
     uintptr_t retaddr;

+    fprintf(stderr, "%s: %08x\n", __func__, addr);
     /* test if there is match for unaligned or IO access */
     /* XXX: could done more in memory macro in a non portable way */
     index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
@@ -263,6 +264,7 @@ void glue(glue(glue(HELPER_PREFIX, st), SUFFIX),
MMUSUFFIX)(ENV_PARAM
     uintptr_t retaddr;
     int index;

+    fprintf(stderr, "%s: %08x\n", __func__, addr);
     index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
  redo:
     tlb_addr = env->tlb_table[mmu_idx][index].addr_write;


-- 
Thanks.
-- Max

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

[Laurent Desnogues]

On Thu, Aug 16, 2012 at 7:49 PM, Steven <wangwangkang@gmail.com> 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.


Laurent

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

[Steven]

On Thu, Aug 16, 2012 at 2:51 PM, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 7:49 PM, Steven <wangwangkang@gmail.com> 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.

>
>
> Laurent

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

[陳韋任 (Wei-Ren Chen)]

> > On Thu, Aug 16, 2012 at 7:49 PM, Steven <wangwangkang@gmail.com> 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,
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).

HTH,
chenwj

[1] http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg03060.html

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

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

[Max Filippov]

On Fri, Aug 17, 2012 at 3:14 PM, 陳韋任 (Wei-Ren Chen)
<chenwj@iis.sinica.edu.tw> wrote:
>> > On Thu, Aug 16, 2012 at 7:49 PM, Steven <wangwangkang@gmail.com> 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

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

[陳韋任 (Wei-Ren Chen)]

On Fri, Aug 17, 2012 at 03:57:55PM +0400, Max Filippov wrote:
> On Fri, Aug 17, 2012 at 3:14 PM, 陳韋任 (Wei-Ren Chen)
> <chenwj@iis.sinica.edu.tw> wrote:
> >> > On Thu, Aug 16, 2012 at 7:49 PM, Steven <wangwangkang@gmail.com> 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:

  Ya, I know. :) Just try to explain what Laurent want to say.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

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 <jcmvbkbc@gmail.com> wrote:
> On Fri, Aug 17, 2012 at 3:14 PM, 陳韋任 (Wei-Ren Chen)
> <chenwj@iis.sinica.edu.tw> wrote:
>>> > On Thu, Aug 16, 2012 at 7:49 PM, Steven <wangwangkang@gmail.com> 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

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

[Max Filippov]

On Tue, Aug 21, 2012 at 9:40 AM, Steven <wangwangkang@gmail.com> wrote:
> 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.

I see two possibilities here:
- maybe there are more fast path shortcuts in the QEMU code?
  in that case output of qemu -d op,out_asm would help.
- maybe your compiler had optimized that sample code?
  could you try to declare array in your sample as 'volatile int'?

-- 
Thanks.
-- Max

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

[Max Filippov]

On Sat, Aug 25, 2012 at 9:20 PM, Steven <wangwangkang@gmail.com> wrote:
> On Tue, Aug 21, 2012 at 3:18 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> On Tue, Aug 21, 2012 at 9:40 AM, Steven <wangwangkang@gmail.com> wrote:
>>> 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.
>>
>> I see two possibilities here:
>> - maybe there are more fast path shortcuts in the QEMU code?
>>   in that case output of qemu -d op,out_asm would help.
>> - maybe your compiler had optimized that sample code?
>>   could you try to declare array in your sample as 'volatile int'?
> After adding the "volatile" qualifier, the results are correct now.
> So your patch can trap all the guest memory data load access, no
> matter slow path or fast path.
>
> However, I found some problem when I try understanding the instruction
> access. So I run the VM with "-d in_asm" to see program counter of
> each guest code. I got
>
> __ldl_cmmu,ffffffff8102ff91
> __ldl_cmmu,ffffffff8102ff9a
> ----------------
> IN:
> 0xffffffff8102ff8a:  mov    0x8(%rbx),%rax
> 0xffffffff8102ff8e:  add    0x790(%rbx),%rax
> 0xffffffff8102ff95:  xor    %edx,%edx
> 0xffffffff8102ff97:  mov    0x858(%rbx),%rcx
> 0xffffffff8102ff9e:  cmp    %rcx,%rax
> 0xffffffff8102ffa1:  je     0xffffffff8102ffb0
> .....
>
> __ldl_cmmu,00000000004005a1
> __ldl_cmmu,00000000004005a6
> ----------------
> IN:
> 0x0000000000400594:  push   %rbp
> 0x0000000000400595:  mov    %rsp,%rbp
> 0x0000000000400598:  sub    $0x20,%rsp
> 0x000000000040059c:  mov    %rdi,-0x18(%rbp)
> 0x00000000004005a0:  mov    $0x1,%edi
> 0x00000000004005a5:  callq  0x4004a0
>
> From the results, I see that the guest virtual address of the pc is
> slightly different between the __ldl_cmmu and the tb's pc(below IN:).
> Could you help to understand this? Which one is the true pc memory
> access? Thanks.

Guest code is accessed at the translation time by C functions and
I guess there are other layers of address translation caching. I wouldn't
try to interpret these _cmmu printouts and would instead instrument
[cpu_]ld{{u,s}{b,w},l,q}_code macros.

-- 
Thanks.
-- Max

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

[Steven]

On Sat, Aug 25, 2012 at 4:41 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Sat, Aug 25, 2012 at 9:20 PM, Steven <wangwangkang@gmail.com> wrote:
>> On Tue, Aug 21, 2012 at 3:18 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>> On Tue, Aug 21, 2012 at 9:40 AM, Steven <wangwangkang@gmail.com> wrote:
>>>> 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.
>>>
>>> I see two possibilities here:
>>> - maybe there are more fast path shortcuts in the QEMU code?
>>>   in that case output of qemu -d op,out_asm would help.
>>> - maybe your compiler had optimized that sample code?
>>>   could you try to declare array in your sample as 'volatile int'?
>> After adding the "volatile" qualifier, the results are correct now.
>> So your patch can trap all the guest memory data load access, no
>> matter slow path or fast path.
>>
>> However, I found some problem when I try understanding the instruction
>> access. So I run the VM with "-d in_asm" to see program counter of
>> each guest code. I got
>>
>> __ldl_cmmu,ffffffff8102ff91
>> __ldl_cmmu,ffffffff8102ff9a
>> ----------------
>> IN:
>> 0xffffffff8102ff8a:  mov    0x8(%rbx),%rax
>> 0xffffffff8102ff8e:  add    0x790(%rbx),%rax
>> 0xffffffff8102ff95:  xor    %edx,%edx
>> 0xffffffff8102ff97:  mov    0x858(%rbx),%rcx
>> 0xffffffff8102ff9e:  cmp    %rcx,%rax
>> 0xffffffff8102ffa1:  je     0xffffffff8102ffb0
>> .....
>>
>> __ldl_cmmu,00000000004005a1
>> __ldl_cmmu,00000000004005a6
>> ----------------
>> IN:
>> 0x0000000000400594:  push   %rbp
>> 0x0000000000400595:  mov    %rsp,%rbp
>> 0x0000000000400598:  sub    $0x20,%rsp
>> 0x000000000040059c:  mov    %rdi,-0x18(%rbp)
>> 0x00000000004005a0:  mov    $0x1,%edi
>> 0x00000000004005a5:  callq  0x4004a0
>>
>> From the results, I see that the guest virtual address of the pc is
>> slightly different between the __ldl_cmmu and the tb's pc(below IN:).
>> Could you help to understand this? Which one is the true pc memory
>> access? Thanks.
>
> Guest code is accessed at the translation time by C functions and
> I guess there are other layers of address translation caching. I wouldn't
> try to interpret these _cmmu printouts and would instead instrument
> [cpu_]ld{{u,s}{b,w},l,q}_code macros.
yes, you are right.
Some ldub_code in x86 guest does not call __ldq_cmmu when the tlb hits.
By the way, when I use your patch, I saw too many log event for the
kernel data _mmu, ie., the addrs is
0x7fff ffff ffff. There are too many such mmu event that the user mode
data can not be executed. So I have to  setup a condition like
     if (addr < 0x8000 0000 0000)
            fprintf(stderr, "%s: %08x\n", __func__, addr);
Then my simple array access program can be finished.
I am wondering whether you have met the similar problem or you have
any suggestion on this.
My final  goal is to obtain the memory access trace for a particular
process in the guest, so your patch really helps, except for too many
kernel _mmu events.

steven
>
> --
> Thanks.
> -- Max

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

[陳韋任 (Wei-Ren Chen)]

> My final  goal is to obtain the memory access trace for a particular
> process in the guest, so your patch really helps, except for too many
> kernel _mmu events.

  How do you know guest is running which process, and log it's memory
access trace?

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

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

[Steven]

I added a special opcode, which is not used by existing x86. When the
process in the guest issues this opcode, the qemu starts to log its
mmu access.



On Mon, Aug 27, 2012 at 11:14 PM, 陳韋任 (Wei-Ren Chen)
<chenwj@iis.sinica.edu.tw> wrote:
>> My final  goal is to obtain the memory access trace for a particular
>> process in the guest, so your patch really helps, except for too many
>> kernel _mmu events.
>
>   How do you know guest is running which process, and log it's memory
> access trace?
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Computer Systems Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
> Homepage: http://people.cs.nctu.edu.tw/~chenwj

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

[Max Filippov]

On Mon, Aug 27, 2012 at 8:15 PM, Steven <wangwangkang@gmail.com> wrote:
>> Guest code is accessed at the translation time by C functions and
>> I guess there are other layers of address translation caching. I wouldn't
>> try to interpret these _cmmu printouts and would instead instrument
>> [cpu_]ld{{u,s}{b,w},l,q}_code macros.
> yes, you are right.
> Some ldub_code in x86 guest does not call __ldq_cmmu when the tlb hits.
> By the way, when I use your patch, I saw too many log event for the
> kernel data _mmu, ie., the addrs is
> 0x7fff ffff ffff. There are too many such mmu event that the user mode
> data can not be executed. So I have to  setup a condition like
>      if (addr < 0x8000 0000 0000)
>             fprintf(stderr, "%s: %08x\n", __func__, addr);
> Then my simple array access program can be finished.

You can also try to differentiate kernel/userspace by mmu_idx passed to
helpers.

> I am wondering whether you have met the similar problem or you have
> any suggestion on this.

I used simple samples (tests/tcg/xtensa testsuite), their memory access
pattern didn't deviate from what I expected.

> My final  goal is to obtain the memory access trace for a particular
> process in the guest, so your patch really helps, except for too many
> kernel _mmu events.

Wouldn't it be easier to use qemu-user for that?

-- 
Thanks.
-- Max