> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > Sent: Monday, February 6, 2023 12:31 PM > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Saturday, February 4, 2023 1:41 AM > > > > On Thu, Feb 02, 2023 at 05:34:15AM +0000, Liu, Yi L wrote: > > > > > This seems to be ok. The group path will attach the group to an auto- > > allocated > > > iommu_domain, while the cdev path actually waits for userspace to > > > attach it to an IOAS. Userspace should take care of it. It should ensure > > > the devices in the same group should be attached to the same domain. > > > > Aren't there problems when someone closes the group or device FD while > > the other one is still open though? > > Guess no. userspace can only open devices from the same group by both > group path and cdev path when the group path is iommufd compat mode > and uses the same iommufd as cdev path. This means the attach API are > the same in the two paths. I think iommufd attach API is able to manage > one device is closed while other devices are still attached. > I guess the problem is on DMA ownership. iommu_group_release_dma_owner() just blindly set group->owner_cnt to 0. So if someone closes the group FD while cdev FD is still open, the ownership model is completely broken. IMHO using iommufd_ctx to mark DMA ownership for iommufd compat doesn't sound right. The group claim/release helpers are not designed to be exclusive but due to sharing internal logic with device claim/release we then allow group/cdev to share ownership when a same owner is marked. It's probably simpler if we always mark DMA owner with vfio_group for the group path, no matter vfio type1 or iommufd compat is used. This should avoid all the tricky corner cases between the two paths. Thanks Kevin
