Re: Instructions for clock sync for tracing host/guest

From: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Dario Faggioli <dfaggioli@suse.com>,
	Joel Fernandes <joelaf@google.com>,
	"Yordan Karadzhov (VMware)" <y.karadz@gmail.com>,
	Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: Instructions for clock sync for tracing host/guest
Date: Mon, 26 Apr 2021 18:02:58 +0300	[thread overview]
Message-ID: <CAPpZLN7q_nQg8A65P4w3OjoN8GiujpCnYwjBJVYbWyLBkb1OHQ@mail.gmail.com> (raw)
In-Reply-To: <20210426105111.288280bb@gandalf.local.home>

On Mon, Apr 26, 2021 at 5:51 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> 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.

For a complete mapping, some handshake logic should be implemented -
to force the guest to use all its CPUs, and to ensure we have the
mapping for each vCPU.
The other approach could be to look in /proc - the relation between
KVM thread 129042 and the VM process is there.

>
> -- Steve

-- 
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center