On 11/06/2015 03:15 AM, Peter Maydell wrote:
On 6 November 2015 at 11:12, Stefan Hajnoczi <stefa...@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
<http://osdir.com/ml/qemu-devel/2013-07/msg04848.html> 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
