Hi Perter,

I read some code lines of QEMU in the past week and have more understanding about QEMU. But there are also a lot of things unclear in my mind. And I beg you help me again.

First, I found there are some x86 instructions translated from TCG instructions will access the "RAM device" directly. Do you think so? Is it fast path you said? And the slow path means it's necessary to call these functions in softmmu_template.h (such as glue(glue(__ld, SUFFIX), MMUSUFFIX)) to get the host virtual address from guest virtual address. If the access the "RAM device" directly is true, I think it is very difficult to monitor. Do you have a good idea?

Second,  about the following suggestion:

You might find it simpler to attack the problem at a higher level
by modifying the translator to output calls to tracing helper functions
before every load/store instruction.

Did it means add an new TCG instructions to tracing it? The new TCG instruction will be generated when disassemble ARM LD/ST instructions, and then the new TCG instruction will generate the call of tracing helper function when they are translated to X86. In the tracing helper function, the RAM access log will out put. Does these your means?

Thanks,
Jerry

2012/3/15 Peter Maydell <peter.maydell@linaro.org>
2012/3/15 ܴ <uulinux@gmail.com>:
> Dear Peter Maydell,
>
> Thank you for your help. I got an idea to log the guest physical address,
> would you mind help me to check it?
>
> Because the function tcg_out_qemu_ld() and tcg_out_qemu_st() know the guest
> virtual address should be accessed, we can call the
> [target-arm/helper.c:get_phys_addr] function to translate the guest virtual
> address to the guest physical address and log the guest physical address.
>
> Is it feasible? I know it will be slow the QEMU.

Depends what you mean by 'feasible'. It's not totally impossible.
Bear in mind that you'll have to write C code which writes out
x86 instructions which do the actual function call, and that
you will need to do it without accidentally trashing any registers
which are in use at that point. You'll also need to find all the
slow path accesses which don't go through this point.

You might find it simpler to attack the problem at a higher level
by modifying the translator to output calls to tracing helper functions
before every load/store instruction.

This is all getting pretty complicated, though, and I wouldn't recommend it
without a decent understanding of how QEMU works...

-- PMM



--
I love linux!!!