Re: Instructions for clock sync for tracing host/guest

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 26 Apr 2021 17:38:09 +0200
Dario Faggioli <dfaggioli@suse.com> wrote:

> Yeah, that was kind of my point. Any VMEnter, from any of the vCPUs
> will give us a PID, the one of a vCPU thread. From that PID, we can
> look up the PID of the process that created the vCPU (although, I don't
> know how, except scanning).

But that's implementation specific to the creation of the VM. Can we rely
on that?

> 
> With the PID of the creating process you can tell (e.g., still from
> /proc) the number of the vm-fd, and we have everything to reach TSC
> offsets in debugfs... Isn't that so?

I'm not sure what you mean here.

> 
> What about the vhost cid and port? If they're on the command line (as
> they are for QEMU), of course we have them in /proc too. IDK if crossvm
> (and other VMMs) also have them on the  command line, though.

If possible, I'd like to avoid parsing cmdlines. We can do that for now if
the user uses libvirt and just passes the name of the guest:

 -A Fedora21

But if you pass the vsock id:

 -A guest@3:823

then all bets are off, as we do not know what implementation is running the
guest. The most robust way would be to use the trace events of the sched
wake ups as I mentioned. This way, when trace-cmd talks with the guest
agent, we can follow the wake ups and find which thread is communicating
with the guest on behalf of trace-cmd. This removes all reliance on the
user space implementation.

BTW, when checking wake ups, you need to ignore any wake up that is done in
an interrupt. As those may not be related to the communication to the guest.

-- Steve