> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, November 23, 2022 9:03 PM > > On Wed, Nov 23, 2022 at 01:33:22AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Friday, November 18, 2022 11:22 PM > > > > > > On Fri, Nov 18, 2022 at 02:58:49AM +0000, Tian, Kevin wrote: > > > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > > > Sent: Thursday, November 17, 2022 5:01 AM > > > > > index ca28a135b9675f..2fdff04000b326 100644 > > > > > --- a/drivers/iommu/iommufd/Makefile > > > > > +++ b/drivers/iommu/iommufd/Makefile > > > > > @@ -5,6 +5,7 @@ iommufd-y := \ > > > > > io_pagetable.o \ > > > > > ioas.o \ > > > > > main.o \ > > > > > - pages.o > > > > > + pages.o \ > > > > > + vfio_compat.o > > > > > > > > > > > > > move vfio_compat out of core? it's not required if VFIO > > > > is not configured. > > > > > > We can, but I don't know if we should. Compat ioctls are part of > > > /dev/iommu, and technically have nothing to do with VFIO. A native > > > iommufd application using VDPA could use them, if it wanted, for > > > instance. > > > > > > > I'm not sure whether that requires further VDPA support. Be safe > > I'd like VDPA to explicitly select vfio_compact when that new > > mixed scheme is supported. > > It doesn't make any sense. The ioctls provided by the "vfio container" > FD are entirely up to IOMMUFD, it doesn't matter what the consuming > subsystem is. Just think of them as alternatives to the existing > map/unmap iommfd provides in its native mode. > > If you want to disable them is a decision that is driven more by > eliminating the code from the kernel because you know your userspace > doesn't use those ioctls - which has nothing to do if vfio is compiled > in or not. if this can be compiled out then there is a dependency imposed by vfio when vfio container is off. but this is a small issue which I won't insist, so: Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
