RE: [PATCH] vdpa: allow vdpa dev_del management operation to return failure

[Parav Pandit]

> From: Jason Wang <jasowang@xxxxxxxxxx>
> 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.