Re: Instructions for clock sync for tracing host/guest

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 26 Apr 2021 16:11:46 +0200
Dario Faggioli <dfaggioli@suse.com> wrote:

> I can't double check as I don't have a crossvm environment handy, but I
> guess it looks the same, and the PID is the one of whatever task in
> crossvm issues the KVM_CREATE_VM ioctl (and the fd returned by such
> call).
> 
> In QEMU, such process then creates one thread for each vCPU... Again, I

I'm sure all implementations will do the same. Anything else would not make
sense.

> don't really know for sure, but I guess it would be similar in crossvm?
> 
> If yes, AFAICT, kvm_entry events can tell us the PIDs of such threads.
> So the challenge here is getting from the PID of a thread to the PID of
> the process that created it.

As I stated in the other thread, we can find the thread that is running the
vCPU by following the wake ups. A vsock connection will trigger a series of
events that will eventually wake up a task that does a kvm_entry. Then you
know the thread.

Here's another run:

    vsock-client-160552 [001] 403952.847983: sched_wakeup:         vhost-128994:129046 [120] success=1 CPU:003

    vhost-128994-129046 [003] 403952.848030: sched_wakeup:         CPU 0/KVM:129042 [120] success=1 CPU:006

       CPU 0/KVM-129042 [006] 403952.848085: kvm_entry:            vcpu 0


We see that our process (PID 160552) wakes up 129046 which then wakes up
129042, which does a kvm_entry for vcpu 0. Since process 160552 is
communicating with the guest, we know that this series of events will wake
up the guest we want to map the thread and the vCPU of the guest with.

As it was thread 129042 that called kvm_entry, it's the thread that is
mapped to vcpu 0 of the guest we are tracing.

-- Steve