On Mon, 26 Apr 2021 17:38:09 +0200 Dario Faggioli <dfaggioli@xxxxxxxx> wrote: > 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). But that's implementation specific to the creation of the VM. Can we rely on that? > > 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? I'm not sure what you mean here. > > 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. If possible, I'd like to avoid parsing cmdlines. We can do that for now if the user uses libvirt and just passes the name of the guest: -A Fedora21 But if you pass the vsock id: -A guest@3:823 then all bets are off, as we do not know what implementation is running the guest. The most robust way would be to use the trace events of the sched wake ups as I mentioned. This way, when trace-cmd talks with the guest agent, we can follow the wake ups and find which thread is communicating with the guest on behalf of trace-cmd. This removes all reliance on the user space implementation. BTW, when checking wake ups, you need to ignore any wake up that is done in an interrupt. As those may not be related to the communication to the guest. -- Steve
|