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. Jason
