On 11/06/2015 03:15 AM, Peter Maydell wrote:
On 6 November 2015 at 11:12, Stefan Hajnoczi <stefanha@gmail.com> wrote:

On Mon, Nov 02, 2015 at 09:18:03AM -0800, Hollis Blanchard wrote:

I'm trying to use the memory_region_ops_read/write tracepoints. They produce
output like this:

   memory_region_ops_write 0.000 pid=8861 mr=0x185b1e8 addr=0x0
   value=0x3 size=0x4
   memory_region_ops_write 165.000 pid=8861 mr=0x185b1e8 addr=0x80
   value=0xffffffff size=0x4
   memory_region_ops_write 155.000 pid=8861 mr=0x1914240 addr=0x0
   value=0x3 size=0x4
   memory_region_ops_write 2.000 pid=8861 mr=0x185b320 addr=0x0
   value=0x3 size=0x4
   memory_region_ops_write 134.000 pid=8861 mr=0x1914240 addr=0x4
   value=0x80 size=0x4

How do I discover which devices are represented by MemoryRegions 0x185b1e8
and 0x1914240? Or alternatively how do I discover the full addresses?

As a KVM user I use the kvm:kvm_mmio and kvm:kvm_pio kernel trace
events.

Is there a reason why we can't print the mr->name in this tracing?

That works, and I was going to suggest it if there's no better answer. I'm not sure however if it's possible to disambiguate the trace messages if you have multiple instances of the same device type. Other improvements could be important too, like displaying which core was performing the access. So maybe just displaying the name first is a good step forward for now, and separately there's an improvement wishlist for the future.

I was just confused because Paolo's original patch said "This is quite handy to debug softmmu targets", so I figured I must be missing something that would make it handy. :-)

By the way, docs/tracing.txt says:
The "simple" backend currently does not capture string arguments, it simply
records the char* pointer value instead of the string that is pointed to.
This seems no longer to be the case, because string arguments display fine for me...

Hollis Blanchard
Mentor Graphics Emulation Division