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. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
