On Mon, Apr 26, 2021 at 5:51 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Mon, 26 Apr 2021 16:11:46 +0200 > Dario Faggioli <dfaggioli@xxxxxxxx> 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
|