On 04/24/2015 08:46 AM, Peter Maydell wrote: > On 24 April 2015 at 12:26, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 24/04/2015 04:10, Wenjie Liu wrote: >>> The thing I am trying to achieve is to get the data and guest physical >>> address of every guest memory access, so I need to known which API can >>> be used to do the address transform. >> >> The short answer is that is difficult, because most guest memory >> accesses do not call any C function. QEMU has a virtual TLB; if you >> have a TLB hit, the code generated by the JIT compiler does the conversion. > > In fact on a TLB hit it's possible that it's not actually any > longer determinable what the guest physical address was. This > only really happens with buggy guests, but if the guest does > a load that brings an entry into the TLB and then rewrites the > page table but fails to do the TLB maintenance operation, then > at the point when a subsequent load hits in the TLB we know > the guest virtual address and the host virtual address but not > the guest physical address, and we can't find the guest physaddr > any more even if we walk the page tables, because those have > been changed... > > Wanting to do this kind of memory access tracing is a pretty > common user request, though, and it would be nice if QEMU > had the facilities for it. It's just that our current design > is really not set up to make it easy to implement.
While probably very slow, could the kind of guest memory trace in question be captured using the GDB stub and a breakpoint on every load an store instruction (or alternatively, a watchpoint on every possible address)? Chris -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
