On Wed, Feb 08, 2023 at 04:23:16AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Tuesday, February 7, 2023 9:27 PM > > > > > > > > No, I mean why can't vfio just call iommufd exactly once regardless of > > > > what mode it is running in? > > > > > > This seems to be moving the DMA owner claim out of > > iommufd_device_bind(). > > > Is it? Then either group and cdev can claim DMA owner with their own > > DMA > > > marker. > > > > No, it has nothing to do with DMA ownership > > > > Just keep a flag in vfio saying it is in group mode or device mode and > > act accordingly. > > It cannot be a simple flag. needs to be a refcnt since multiple devices > in the group might be opened via cdev so the device mode should be > cleared only when the last device via cdev is closed. > > Yi actually did implement such a flavor before, kind of introducing > a vfio_group->cdev_opened_cnt field. > > Then cdev bind_iommufd checks whether vfio_group->opened_file > has been set in the group open path. If not then increment > vfio_group->cdev_opened_cnt. > > cdev close decrements vfio_group->cdev_opened_cnt. > > group open checks whether vfio_group->cdev_opened_cnt has been > set. If not go to set vfio_group->opened_file. > > In this case only one path can claim DMA ownership. > > Is above what you expect? It seems appropriate You could also sweep the device list to see how the indivudal devices are open to decice what to do. > > The iommufd DMA owner check is *only* to be used for protecting > > against two unrelated drivers trying to claim the same device. > > > > this is just one implementation choice. I don't see why it cannot be > extended to allow one driver to protect against two internal paths. > Just simply allow the driver to assign an owner instead of assuming > iommufd_ctx. It is really not what it is for, and the owner thing is so ugly I don't like the pattern. Jason
