search for: vhost_set_own

On Tue, Mar 21, 2023 at 11:42?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > When the user call VHOST_SET_OWNER ioctl and the vDPA device > has `use_va` set to true, let's call the bind_mm callback. > In this way we can bind the device to the user address space > and directly use the user VA. > > The unbind_mm callback is called during the release after > stopping the device. > &gt...

On 6/6/23 4:49 AM, Stefano Garzarella wrote: > On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >> If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >> can race where: >> 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >> 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >> 3. vhost_worker_create will set the dev->worker pointer before setting >> the worker->vtsk pointer....

On Tue, Jun 06, 2023 at 12:19:10PM -0500, Mike Christie wrote: > On 6/6/23 4:49 AM, Stefano Garzarella wrote: > > On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: > >> If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we > >> can race where: > >> 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue > >> 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. > >> 3. vhost_worker_create will set the dev->worker pointer before setting > >> the...

When the user call VHOST_SET_OWNER ioctl and the vDPA device has `use_va` set to true, let's call the bind_mm callback. In this way we can bind the device to the user address space and directly use the user VA. The unbind_mm callback is called during the release after stopping the device. Signed-off-by: Stefano Garzarella &l...

On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >can race where: >1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >3. vhost_worker_create will set the dev->worker pointer before setting >the worker->vtsk pointer. >4. thread0's vhos...

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see th...

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see th...

...This may help to avoid confusion when we want to develop >>>>> new API for e.g dirty page tracking. >>>> Good point. It's better to reject these ioctls for now. >>>> >>>> PS. One thing I may need to clarify is that, we need the >>>> VHOST_SET_OWNER ioctl to get the vq->handle_kick to work. >>>> So if we don't call vhost_dev_ioctl(), we will need to >>>> call vhost_dev_set_owner() directly. >> I may miss something, it looks to me the there's no owner check in >> vhost_vring_ioctl() and the vhost...

...the final fput/release > should always come from vhost_worker's sub-thread (which shares mm/etc) ? I think I'm misunderstanding the sub-thread term. - Is it the task_struct's context that we did the kernel/vhost_taskc.c:vhost_task_create() from? Below it would be the thread we did VHOST_SET_OWNER from. If so, then yes. - Is it the task_struct that gets created by kernel/vhost_taskc.c:vhost_task_create()? If so, then the answer is no. vhost_task_create has set the no_files arg on kernel_clone_args, so copy_files() sets task_struct->files to NULL and we don't clone or dup the file...

...should always come from vhost_worker's sub-thread (which shares mm/etc) ? > > I think I'm misunderstanding the sub-thread term. > > - Is it the task_struct's context that we did the > kernel/vhost_taskc.c:vhost_task_create() from? Below it would be the > thread we did VHOST_SET_OWNER from. Yes, > So it works like if we were using a kthread still: > > 1. Userapce thread0 opens /dev/vhost-$something. > 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to > create the task_struct which runs the vhost_worker() function which handles > the w...

...vhost_worker's sub-thread (which shares mm/etc) ? >> >> I think I'm misunderstanding the sub-thread term. >> >> - Is it the task_struct's context that we did the >> kernel/vhost_taskc.c:vhost_task_create() from? Below it would be the >> thread we did VHOST_SET_OWNER from. > > Yes, > >> So it works like if we were using a kthread still: >> >> 1. Userapce thread0 opens /dev/vhost-$something. >> 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to >> create the task_struct which runs the vhost_worker(...

...gt; drivers should know that the addresses used in ctrl vq are >> host virtual addresses in vhost-mdev's case. > > > That's really good point. And that means parent needs to differ vhost > from virtio. It should work. HVA may only work when we have something similar to VHOST_SET_OWNER which can reuse MM of its owner. > But is there any chance to use DMA address? I'm asking since the API > then tends to be device specific. I wonder whether we can introduce MAP IOMMU notifier and get DMA mappings from that. Thanks

...gt; drivers should know that the addresses used in ctrl vq are >> host virtual addresses in vhost-mdev's case. > > > That's really good point. And that means parent needs to differ vhost > from virtio. It should work. HVA may only work when we have something similar to VHOST_SET_OWNER which can reuse MM of its owner. > But is there any chance to use DMA address? I'm asking since the API > then tends to be device specific. I wonder whether we can introduce MAP IOMMU notifier and get DMA mappings from that. Thanks

...6/06, Mike Christie wrote: > > On 6/6/23 7:16 AM, Oleg Nesterov wrote: > > On 06/05, Mike Christie wrote: > > > >> So it works like if we were using a kthread still: > >> > >> 1. Userapce thread0 opens /dev/vhost-$something. > >> 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to > >> create the task_struct which runs the vhost_worker() function which handles > >> the work->fns. > >> 3. If userspace now does a SIGKILL or just exits without doing a close() on > >> /dev/vhost-$something, then wh...

The following patches made over Linus's tree fix the 2 bugs: 1. vhost worker task shows up as a process forked from the parent that did VHOST_SET_OWNER ioctl instead of a process under root/kthreadd. This was causing breaking scripts. 2. vhost_tasks didn't disable or add support for freeze requests. The following patches fix these issues by making the vhost_task task a thread under the process that did the VHOST_SET_OWNER and uses get_signa...

...ost.c @@ -917,6 +917,11 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp) long r; int i, fd; + if (ioctl == VHOST_GET_MEM_MAX_NREGIONS) { + r = VHOST_MEMORY_MAX_NREGIONS; + goto done; + } + /* If you are not the owner, you can become one */ if (ioctl == VHOST_SET_OWNER) { r = vhost_dev_set_owner(d); -- MST

...ost.c @@ -917,6 +917,11 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp) long r; int i, fd; + if (ioctl == VHOST_GET_MEM_MAX_NREGIONS) { + r = VHOST_MEMORY_MAX_NREGIONS; + goto done; + } + /* If you are not the owner, you can become one */ if (ioctl == VHOST_SET_OWNER) { r = vhost_dev_set_owner(d); -- MST

...s used in ctrl vq are > > > host virtual addresses in vhost-mdev's case. > > > > > > That's really good point. And that means parent needs to differ vhost > > from virtio. It should work. > > > HVA may only work when we have something similar to VHOST_SET_OWNER which > can reuse MM of its owner. We already have VHOST_SET_OWNER in vhost now, parent can handle the commands in its .kick_vq() which is called by vq's .handle_kick callback. Virtio-user did something similar: https://github.com/DPDK/dpdk/blob/0da7f445df445630c794897347ee360d6fe6348b/d...

...vent vq >> vq=2 and above: SCSI CMD/IO vqs. We want to create N of these. >> >> Today we do: >> >> Uerspace does open(/dev/vhost-scsi) >> vhost_dev_init(create 128 vqs and then later we setup and use N of >> them); >> >> Qemu does ioctl(VHOST_SET_OWNER) >> vhost_dev_set_owner() >> >> For N vqs userspace does: >> // virtqueue setup related ioctls >> >> Qemu does ioctl(VHOST_SCSI_SET_ENDPOINT) >> - match LIO/target port to vhost_dev >> >> >> So we could change...

...*argp) > > long r; > > int i, fd; > > > > + if (ioctl == VHOST_GET_MEM_MAX_NREGIONS) { > > + r = VHOST_MEMORY_MAX_NREGIONS; > > + goto done; > > + } > > + > > /* If you are not the owner, you can become one */ > > if (ioctl == VHOST_SET_OWNER) { > > r = vhost_dev_set_owner(d);