+17
−1
+10
−1
+4
−0
Loading
These trace events were very useful to help me to understand and find a reordering issue in vfio, for example: qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 that also helped me to see the desired result after the fix: qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4) vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 So it could be a good idea to have these traces implemented. It's worth mentioning that they should be surgically enabled during the debugging, otherwise it can flood the trace logs with lock/unlock messages. How to use it: trace-event qemu_mutex_lock on|off trace-event qemu_mutex_unlock on|off or trace-event qemu_mutex* on|off Signed-off-by:Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com> Reviewed-by:
Fam Zheng <famz@redhat.com> [Also handle trylock, cond_wait and win32; trace "unlocked" while still in the critical section, so that "unlocked" always comes before the next "locked" tracepoint. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>