lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Dec 2022 09:13:03 +0100 From: Stefano Garzarella <sgarzare@...hat.com> To: Jason Wang <jasowang@...hat.com> Cc: virtualization@...ts.linux-foundation.org, Andrey Zhadchenko <andrey.zhadchenko@...tuozzo.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org, "Michael S. Tsirkin" <mst@...hat.com>, eperezma@...hat.com, stefanha@...hat.com, netdev@...r.kernel.org Subject: Re: [RFC PATCH 6/6] vdpa_sim: add support for user VA On Fri, Dec 16, 2022 at 03:26:46PM +0800, Jason Wang wrote: >On Thu, Dec 15, 2022 at 12:31 AM Stefano Garzarella <sgarzare@...hat.com> wrote: >> >> The new "use_va" module parameter (default: false) is used in >> vdpa_alloc_device() to inform the vDPA framework that the device >> supports VA. >> >> vringh is initialized to use VA only when "use_va" is true and the >> user's mm has been bound. So, only when the bus supports user VA >> (e.g. vhost-vdpa). >> >> vdpasim_mm_work_fn work is used to attach the kthread to the user >> address space when the .bind_mm callback is invoked, and to detach >> it when the device is reset. > >One thing in my mind is that the current datapath is running under >spinlock which prevents us from using iov_iter (which may have page >faults). > >We need to get rid of the spinlock first. Right! I already have a patch for that since I used for the vdpa-blk software device in-kernel PoC where I had the same issue. I'll add it to the series! > >> >> Signed-off-by: Stefano Garzarella <sgarzare@...hat.com> >> --- >> drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 + >> drivers/vdpa/vdpa_sim/vdpa_sim.c | 104 ++++++++++++++++++++++++++++++- >> 2 files changed, 103 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h >> index 07ef53ea375e..1b010e5c0445 100644 >> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h >> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h >> @@ -55,6 +55,7 @@ struct vdpasim { >> struct vdpasim_virtqueue *vqs; >> struct kthread_worker *worker; >> struct kthread_work work; >> + struct mm_struct *mm_bound; >> struct vdpasim_dev_attr dev_attr; >> /* spinlock to synchronize virtqueue state */ >> spinlock_t lock; >> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> index 36a1d2e0a6ba..6e07cedef30c 100644 >> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> @@ -36,10 +36,90 @@ module_param(max_iotlb_entries, int, 0444); >> MODULE_PARM_DESC(max_iotlb_entries, >> "Maximum number of iotlb entries for each address space. 0 means unlimited. (default: 2048)"); >> >> +static bool use_va; >> +module_param(use_va, bool, 0444); >> +MODULE_PARM_DESC(use_va, "Enable the device's ability to use VA"); >> + >> #define VDPASIM_QUEUE_ALIGN PAGE_SIZE >> #define VDPASIM_QUEUE_MAX 256 >> #define VDPASIM_VENDOR_ID 0 >> >> +struct vdpasim_mm_work { >> + struct kthread_work work; >> + struct task_struct *owner; >> + struct mm_struct *mm; >> + bool bind; >> + int ret; >> +}; >> + >> +static void vdpasim_mm_work_fn(struct kthread_work *work) >> +{ >> + struct vdpasim_mm_work *mm_work = >> + container_of(work, struct vdpasim_mm_work, work); >> + >> + mm_work->ret = 0; >> + >> + if (mm_work->bind) { >> + kthread_use_mm(mm_work->mm); >> +#if 0 >> + if (mm_work->owner) >> + mm_work->ret = cgroup_attach_task_all(mm_work->owner, >> + current); >> +#endif >> + } else { >> +#if 0 >> + //TODO: check it >> + cgroup_release(current); >> +#endif >> + kthread_unuse_mm(mm_work->mm); >> + } >> +} >> + >> +static void vdpasim_worker_queue_mm(struct vdpasim *vdpasim, >> + struct vdpasim_mm_work *mm_work) >> +{ >> + struct kthread_work *work = &mm_work->work; >> + >> + kthread_init_work(work, vdpasim_mm_work_fn); >> + kthread_queue_work(vdpasim->worker, work); >> + >> + spin_unlock(&vdpasim->lock); >> + kthread_flush_work(work); >> + spin_lock(&vdpasim->lock); >> +} >> + >> +static int vdpasim_worker_bind_mm(struct vdpasim *vdpasim, >> + struct mm_struct *new_mm, >> + struct task_struct *owner) >> +{ >> + struct vdpasim_mm_work mm_work; >> + >> + mm_work.owner = owner; >> + mm_work.mm = new_mm; >> + mm_work.bind = true; >> + >> + vdpasim_worker_queue_mm(vdpasim, &mm_work); >> + > >Should we wait for the work to be finished? Yep, I'm waiting inside vdpasim_worker_queue_mm() calling kthread_flush_work(). If we will use mutex, I think we can avoid the lock release around that call. > >> + if (!mm_work.ret) >> + vdpasim->mm_bound = new_mm; >> + >> + return mm_work.ret; >> +} >> + >> +static void vdpasim_worker_unbind_mm(struct vdpasim *vdpasim) >> +{ >> + struct vdpasim_mm_work mm_work; >> + >> + if (!vdpasim->mm_bound) >> + return; >> + >> + mm_work.mm = vdpasim->mm_bound; >> + mm_work.bind = false; >> + >> + vdpasim_worker_queue_mm(vdpasim, &mm_work); >> + >> + vdpasim->mm_bound = NULL; >> +} >> static struct vdpasim *vdpa_to_sim(struct vdpa_device *vdpa) >> { >> return container_of(vdpa, struct vdpasim, vdpa); >> @@ -66,8 +146,10 @@ static void vdpasim_vq_notify(struct vringh *vring) >> static void vdpasim_queue_ready(struct vdpasim *vdpasim, unsigned int idx) >> { >> struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; >> + bool va_enabled = use_va && vdpasim->mm_bound; >> >> - vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, false, false, >> + vringh_init_iotlb(&vq->vring, vdpasim->features, vq->num, false, >> + va_enabled, >> (struct vring_desc *)(uintptr_t)vq->desc_addr, >> (struct vring_avail *) >> (uintptr_t)vq->driver_addr, >> @@ -96,6 +178,9 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim) >> { >> int i; >> >> + //TODO: should we cancel the works? >> + vdpasim_worker_unbind_mm(vdpasim); > >We probably don't need this since it's the virtio level reset so we >need to keep the mm bound in this case. Otherwise we may break the >guest. It should be the responsibility of the driver to call >config_ops->unbind if it needs to do that. Got it, my biggest concern was when we go from a vhost-vdpa virtio-vdpa, but as you said, in vhost-vdpa I can call unbind before releasing the device. Thanks, Stefano
Powered by blists - more mailing lists