Re: [RFC PATCH] iommufd: Destroy vdevice on device unbind

[Xu Yilun]

On Fri, Jun 13, 2025 at 09:42:02AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 13, 2025 at 07:31:48AM +0000, Tian, Kevin wrote:
> > yeah that seems to be the option if the said life-cycle dependency
> > cannot be removed...
> > 
> > conceptually it's still a bit unclean as the user needs to know that
> > the vdevice object is special after idevice is unbound i.e. it can only
> > be destroyed instead of supporting any other kind of operations.
> 
> I would say userspace is somewhat malfunctioning if it destroys vfio
> before the vdevice. So the main aim here should be to contain the
> resulting mess, but still expect userspace to destroy the vdevice
> without a failure.
> 
> > hmm if the user needs to build certain knowledge anyway can we 
> > go one step further to state that the vdevice will be destroyed
> > automatically once its idevice is unbound so the user shouldn't
> > attempt to explicitly destroy it again after unbind?

I think this statement is complex to user. I'd rather from user POV the
vdev_id's lifecycle is mostly the same as other iommufd objects. The
only difference should be, after idev unbind, vdev_id would be
disfunctional, IOCTLs against the vdev_id would fail except IOMMU_DESTROY.

My understanding of the tombstone idea is:

 - Before idev unbind, IOCTL(IOMMU_DESTROY, vdev_id) could free the vdev
   as normal.
 - On idev unbind, destroy the associate vdev (if exists), but still
   reserve the ictx->objects xa entry.
 - After idev unbind & on IOCTL(IOMMU_DESTROY, vdev_id), just free the
   xa entry if it's a tombstone.
 - On fops_release, free the tombstones if exist.

Thanks,
Yilun

> 
> I would assume a malfunctioning userspace is probably going to destroy
> the vdevice explicitly. If it had proper knowledge it wouldn't have
> done this in the first place :)
> 
> Jason
>