> 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. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
