On Thu, 9 Apr 2020 16:28:34 +0300
"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@xxxxxxxxx> wrote:
> +/**
> + * tracecmd_set_merge_peer - Link a tracing peer to this handle
> + * @handle: input handle for the trace.dat file
> + * @peer: input handle for the tracing peer
> + *
> + * When tracing host and one or more guest machines at the same time,
> + * guest and host are tracing peers. There is information in both trace
> + * files, related to host PID to guest vCPU mapping, timestamp synchronization
> + * and other. This information is useful when opening files at the same time and
> + * merging the events. When the host is set as a tracing peer to the guest, then
> + * the timestamps of guest's events are recalculated to match the host event's time
> + */
> +int tracecmd_set_merge_peer(struct tracecmd_input *handle,
> + struct tracecmd_input *peer)
I wonder it would be better to call this tracecmd_pair_peer(), like
pairing a bluetooth headset with your phone?
> +{
> + if (!handle)
> + return -1;
> +
This should probably fail if the host.peer_data is already set. Which
means we should also have a way to unmerge (unpair) the two. Which is
why I like the term "pair" better, as it is like paring a bluetooth
device and then unpairing it.
-- Steve
> + handle->host.peer_data = peer;
> + tracecmd_ref(peer);
> + tsync_check_enable(handle);
> +
> + return 0;
> +}
> +
> /**
> * tracecmd_ref - add a reference to the handle
> * @handle: input handle for the trace.dat file
> @@ -3785,7 +3839,7 @@ int tracecmd_get_guest_cpumap(struct tracecmd_input *handle,
> */
> unsigned long long tracecmd_get_tsync_peer(struct tracecmd_input *handle)
> {
> - return handle->host.trace_id;
> + return handle->host.peer_trace_id;
> }
>
|