lkml.org 
[lkml]   [2022]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] vdpa: allow vdpa dev_del management operation to return failure
Date


> From: Jason Wang <jasowang@redhat.com>
> Sent: Thursday, June 9, 2022 3:19 AM

[..]

> > > This is to avoid side-effects as noted in
> > > https://bugzilla.kernel.org/show_bug.cgi?id=213179 caused by
> > > deleting the vdpa device when it is being used.
> > > >
> > User should be able to delete the device anytime.
>
> It requires a poll event to user space and then Qemu can release the vhost-
> vDPA device. This is how VFIO works. We probably need to implement
> something like this.
>
Yes, I remember hang with either vfio or vfio-mdev.

> But notice that, at the worst case, usersapce may not respond to this event,
> so there's nothing more kenrel can do execpt for waiting.
>
> We need to consider something different. I used to have an idea to make
> vhost-vdpa couple with vDPA loosely with SRCU/RCU. We might consider
> implementing that.
>
Right. It needs a different solution. As you described, vhost-vdpa cannot rely on the user space involvement in freeing.
Rdma uverbs does that for device removal cases to detach the user space ioctl() context with low level device.

> > Upper layers who are unable to perform teardown sequence should be
> fixed.
>
> I think we probably don't need to bother with failing the dev_del().
> We can consider to fix/workaround the waiting first.
>
Lets fix it as you hinted with S/RCU.
We don’t need to add UAPI for the fix.
UAPI anyway doesn’t work, when driver/system level event occurs such as device fatal error, sriov disablement, sf removal and more.
Vhost-vdpa should be able to detach it from the underlying device.
\
 
 \ /
  Last update: 2022-06-12 20:08    [W:0.097 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site