kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Christie <michael.christie@oracle.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Joel Fernandes <joelaf@google.com>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Linux Trace Devel <linux-trace-devel@vger.kernel.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC][PATCH] vhost/vsock: Add vsock_list file to map cid with vhost tasks
Date: Sat, 8 May 2021 13:32:36 -0500	[thread overview]
Message-ID: <b21a00f5-b3fc-ba01-0660-a1decadaff6f@oracle.com> (raw)
In-Reply-To: <20210505163855.32dad8e7@gandalf.local.home>

On 5/5/21 3:38 PM, Steven Rostedt wrote:
> The new trace-cmd 3.0 (which is almost ready to be released) allows for
> tracing between host and guests with timestamp synchronization such that
> the events on the host and the guest can be interleaved in the proper order
> that they occur. KernelShark now has a plugin that visualizes this
> interaction.
> 
> The implementation requires that the guest has a vsock CID assigned, and on
> the guest a "trace-cmd agent" is running, that will listen on a port for
> the CID. The on the host a "trace-cmd record -A guest@cid:port -e events"
> can be called and the host will connect to the guest agent through the
> cid/port pair and have the agent enable tracing on behalf of the host and
> send the trace data back down to it.
> 
> The problem is that there is no sure fire way to find the CID for a guest.
> Currently, the user must know the cid, or we have a hack that looks for the
> qemu process and parses the --guest-cid parameter from it. But this is
> prone to error and does not work on other implementation (was told that
> crosvm does not use qemu).
> 
> As I can not find a way to discover CIDs assigned to guests via any kernel
> interface, I decided to create this one. Note, I'm not attached to it. If
> there's a better way to do this, I would love to have it. But since I'm not
> an expert in the networking layer nor virtio, I decided to stick to what I
> know and add a debugfs interface that simply lists all the registered CIDs
> and the worker task that they are associated with. The worker task at
> least has the PID of the task it represents.
> 
> Now I can find the cid / host process in charge of the guest pair:
> 
>   # cat /sys/kernel/debug/vsock_list
>   3	vhost-1954:2002
> 

I think I need the same thing for vhost-scsi. We want to know a vhost-scsi
devs worker thread's pid. If we use multiple vhost-devs in one VM then we
wanted to be able to know which thread goes with which dev.

For the vhost thread patches I added an ioctl:

https://lists.linuxfoundation.org/pipermail/virtualization/2021-April/054014.html

but I had originally implemented it in sysfs. For sysfs we can add a struct
device in the vhost_dev and struct deice in the vhost_virtqueue. We then
have a 2 new classes /sys/class/vhost_device and vhost_virtqueue with the
vhost_device device the parent of vhost_virtqueue device.

The nice thing is that it's a common interface and works for every vhost_dev
and all their virtqueues. It works for non libvirt users.

The drawback is adding in refcounts/releases and that type of code for the
vhost_dev and vhost_virtqueue. Also I'm not sure about security.

Note that I'm not tied to sysfs. netlink would be fine. I just need any
interface.

  parent reply	other threads:[~2021-05-08 18:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 20:38 [RFC][PATCH] vhost/vsock: Add vsock_list file to map cid with vhost tasks Steven Rostedt
2021-05-06  1:03 ` Steven Rostedt
2021-05-07 14:11 ` Stefano Garzarella
2021-05-07 14:40   ` Steven Rostedt
2021-05-07 15:43     ` Stefano Garzarella
2021-05-07 16:09       ` Steven Rostedt
2021-05-08 18:32 ` Mike Christie [this message]
2021-05-13 15:57 ` Stefan Hajnoczi
2021-05-13 16:08   ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b21a00f5-b3fc-ba01-0660-a1decadaff6f@oracle.com \
    --to=michael.christie@oracle.com \
    --cc=davem@davemloft.net \
    --cc=joelaf@google.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).