On Thu, 13 May 2021 16:57:34 +0100 Stefan Hajnoczi <stefanha@xxxxxxxxxx> wrote: > This approach relies on process hierarchy of the VMM (QEMU). > Multi-process QEMU is in development and will allow VIRTIO devices to > run as separate processes from the main QEMU. It then becomes harder to > correlate a VIRTIO device process with its QEMU process. And we need to know all these mapping regardless, as we need to map each thread / process to the vCPU in order to correlate between host thread and vCPU thread for showing in KernelShark. Thus this mapping to find the main thread/process needs to be done regardless. > > So I think in the end this approach ends up being as fragile as parsing > command-lines. The kernel doesn't really have the concept of a "VM" that > the vhost_vsock is associated with :). Maybe just parse QEMU and crosvm > command-lines? > That's what we do now, and it already broke once, and even parsing the command line wont be enough for the stated reasons above. -- Steve
