On 6/3/21 9:37 AM, Stefan Hajnoczi wrote: > On Tue, May 25, 2021 at 01:05:51PM -0500, Mike Christie wrote: >> The following patches apply over linus's tree or mst's vhost branch >> and my cleanup patchset: >> >> https://lists.linuxfoundation.org/pipermail/virtualization/2021-May/054354.html >> >> These patches allow us to support multiple vhost workers per device. I >> ended up just doing Stefan's original idea where userspace has the >> kernel create a worker and we pass back the pid. This has the benefit >> over the workqueue and userspace thread approach where we only have >> one'ish code path in the kernel during setup to detect old tools. The >> main IO paths and device/vq setup/teardown paths all use common code. >> >> The kernel patches here allow us to then do N workers device and also >> share workers across devices. >> >> I've also included a patch for qemu so you can get an idea of how it >> works. If we are ok with the kernel code then I'll break that up into >> a patchset and send to qemu-devel. > > It seems risky to allow userspace process A to "share" a vhost worker > thread with userspace process B based on a matching pid alone. Should > they have ptrace_may_access() or similar? > I'm not sure. I already made it a little restrictive in this posting, but it may not be enough depending on what's possible and what we want to allow. Right now to share a worker the userspace process doing the VHOST_SET_VRING_WORKER ioctl has to be the owner. Before we do a VHOST_SET_VRING_WORKER, vhost_dev_ioctl calls vhost_dev_check_owner, so we will fail if 2 random processes try to share. So we can share a worker across a vhost-dev's N virtqueues or share a worker with multiple vhost devs and their virtqueues, but the devs have to be managed by the same VM/qemu process. If that's all we want to support, then is the owner check enough? If we want to share workers across VMs then I think we definitely want something like ptrace_may_access. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
