On Mon, 2021-04-26 at 18:02 +0300, Tzvetomir Stoyanov wrote:
> On Mon, Apr 26, 2021 at 5:51 PM Steven Rostedt <rostedt@goodmis.org>
> wrote:
> > 
> > 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.
> 
Yeah, that was kind of my point. Any VMEnter, from any of the vCPUs
will give us a PID, the one of a vCPU thread. From that PID, we can
look up the PID of the process that created the vCPU (although, I don't
know how, except scanning).

With the PID of the creating process you can tell (e.g., still from
/proc) the number of the vm-fd, and we have everything to reach TSC
offsets in debugfs... Isn't that so?

What about the vhost cid and port? If they're on the command line (as
they are for QEMU), of course we have them in /proc too. IDK if crossvm
(and other VMMs) also have them on the  command line, though.

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)