Re: [RFC][PATCH] vhost/vsock: Add vsock_list file to map cid with vhost tasks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [RFC][PATCH] vhost/vsock: Add vsock_list file to map cid with vhost tasks
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
- Date: Thu, 13 May 2021 12:08:42 -0400
- Cc: LKML <linux-kernel@xxxxxxxxxxxxxxx>, Stefano Garzarella <sgarzare@xxxxxxxxxx>, "Michael S. Tsirkin" <mst@xxxxxxxxxx>, Jason Wang <jasowang@xxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Jakub Kicinski <kuba@xxxxxxxxxx>, kvm@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, Joel Fernandes <joelaf@xxxxxxxxxx>, Linux Trace Devel <linux-trace-devel@xxxxxxxxxxxxxxx>
- In-reply-to: <YJ1Mbie1YGKRR6b8@stefanha-x1.localdomain>
- References: <20210505163855.32dad8e7@gandalf.local.home> <YJ1Mbie1YGKRR6b8@stefanha-x1.localdomain>
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
[Index of Archives]
[Linux USB Development]
[Linux USB Development]
[Linux Audio Users]
[Yosemite Hiking]
[Linux Kernel]
[Linux SCSI]