On Mon, 26 Apr 2021 13:39:32 +0300
Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote:
> > # trace-cmd record -e kvm_entry ssh guest taskset -c 0 ls \; taskset -c 1 cat /etc/passwd
> > # trace-cmd report
> > [..]
> > <...>-129042 [004]1122452427093922: kvm_entry: vcpu 0
> > <...>-129043 [005]1122452427148178: kvm_entry: vcpu 1
> > <...>-129042 [004]1122452427150380: kvm_entry: vcpu 0
> > <...>-129043 [005]1122452427201498: kvm_entry: vcpu 1
> >
> > 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.
Deja vu!
Yes, we had this conversation a long time ago ;-)
I was thinking of doing this during the synchronization phase. We should be
able to figure out the guest host mapping. I have a vsock-client program
that uses the vsockets to talk with the guest (like netcat). And traced it
this way:
# 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
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.
We have our mapping right there! And with the new libtracefs APIs,
implementing the above walk through is trivial.
-- Steve
|