[Question] How To Log QEMU Memory Access

周春华 uulinux at gmail.com
Thu Mar 15 12:21:45 UTC 2012


Dear Peter Maydell,

Thanks for your reply. Would you mind give me more help?

My PC architecture is x86, so the tcg_out_qemu_ld() and tcg_out_qemu_st()
is in tcg/i386/tcg-target.c. Nevertheless, it is difficult for me to
understand them completely.

Do you means that the QEMU TLB maps the guest virtual address to host
virtual address, and the begging and end virtual addresses of the memory
allocated for RAM device emulating are the RAM physical begging and end
address from guest view? If so, it seems hard to monitor the guest physical
memory.

However, [exec.c:qemu_get_ram_ptr] seems to get a host virtual address from
a guest physical address. It confuses me.

Would you mind explain more details about QEMU TLB?

Any comments will be appreciated. Thanks much!

Thanks,
Jerry


2012/3/14 Peter Maydell <peter.maydell at linaro.org>

> On 14 March 2012 14:01, 周春华 <uulinux at gmail.com> wrote:
> > I got a job that should log the RAM memory access in the QEMU. First, I
> > should find out the code line in QEMU to trap all RAM memory access.
> After
> > some efforts, I have some conclusions:
> >
> > 1. I have found the function dealing with the translation from the
> virtual
> > address to physical address in the guest of QEMU, such as
> > [target-arm/helper.c:get_phys_addr], and the page fault handler function
> > [target-arm/helper.c:cpu_arm_handle_mmu_fault]. However, we have not
> found
> > out the routine of accessing physical address from MMU TLB entry.
>
> The TLB lookup and reading of the host RAM is done by generated code
> (for instance on an x86 host this code is generated by tcg_out_qemu_ld()
> and tcg_out_qemu_st() in tcg/i386/tcg-target.c).
>
> NB that the QEMU TLB goes straight from guest virtual address to host
> address when it's reading RAM, without passing through a guest physical
> address.
>
> I'm afraid there's no convenient place to put logging of memory accesses
> in this code, because it is designed for speed rather than ease of
> instrumentation.
>
> -- PMM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-dev/attachments/20120315/cb3bfc67/attachment.html>


More information about the linaro-dev mailing list