Re: Instructions for clock sync for tracing host/guest

[Tzvetomir Stoyanov <tz.stoyanov@gmail.com>]

On Mon, Apr 26, 2021 at 4:24 PM Dario Faggioli <dfaggioli@suse.com> wrote:
>
> On Mon, 2021-04-26 at 08:56 -0400, Steven Rostedt wrote:
> > On Mon, 26 Apr 2021 13:39:32 +0300
> > Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
> > > >
> > > > There, I see the guest vcpu 0 is controlled by the host thread
> > > > with pid
> > > > 129042 and vcpu 1 is controlled by host thread pid 129043.
> > >
> > > It works only in case of one VM, if there are more than one -
> > > cannot
> > > map kvm_entry event to specific VM.
> >
> >  # trace-cmd record -e sched_wakeup -e kvm_entry
> >
> > And have this:
> >
> >     vsock-client-159876 [000]1346877108580652: sched_wakeup:
> > vhost-128994:129046 [120] success=1 CPU:006
> >
> >     vhost-128994-129046 [006]1346877108678708: sched_wakeup:
> > CPU 0/KVM:129042 [120] success=1 CPU:007
> >
> >        CPU 0/KVM-129042 [007]1346877109290044: kvm_entry:
> > vcpu 0
> >
> Mmm... This is quite interesting. But there's something I don't think
> I'm understanding.
>
>
> > Instead of looking at vsock-client, look at the current pid and see
> > what
> > "vhost" it wakes up, then see what what thread it wakes up, and then
> > see if
> > it calls kvm_entry. we don't even need to know if it is a vhost. Just
> > trace
> > everything that our current thread wakes up and what those wake up
> > until
> > something calls kvm_entry.
> >
> So, what's the mapping (like, mapping between what and what) that we
> are interested in here, and what kind of into trick with vsock-client
> is helping us gather, that we don't already have by "just" looking at
> the kvm_entry events?

trace-cmd uses guest name to find:
 <guest name> ->  vhost cid, port
 <guest name> ->  PID of the process, running the VM
PID of the process, running the VM -> PIDs of the threads, running each vCPU

the kvm_entry event has information about mapping <thread PID> to
vCPU, from that thread PID we could find the process which runs the
whole VM. The problem is to find the VM name, vhost cid and port using
that process ID, we couldn't find any generic and reliable way to get
that mapping. That's why the current implementation uses a qemu
specific hack - VM name, vhost cid and port are written in the qemu
command line, which we get from /proc/<qemu pid> and parse. This does
not work with non-qemu VMs.

>
> Regards
> --
> Dario Faggioli, Ph.D
> http://about.me/dario.faggioli
> Virtualization Software Engineer
> SUSE Labs, SUSE https://www.suse.com/
> -------------------------------------------------------------------
> <<This happens because _I_ choose it to happen!>> (Raistlin Majere)

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