On 13/10/2023 18:28, Jason Gunthorpe wrote: > On Fri, Oct 13, 2023 at 06:23:09PM +0100, Joao Martins wrote: >> On 13/10/2023 18:16, Jason Gunthorpe wrote: >>> On Fri, Oct 13, 2023 at 06:10:04PM +0100, Joao Martins wrote: >>>> On 13/10/2023 17:00, Joao Martins wrote: >>>>> On 13/10/2023 16:48, Jason Gunthorpe wrote: >>>>>> On Sat, Sep 23, 2023 at 02:24:54AM +0100, Joao Martins wrote: >>>> But if it's exists an IOMMUFD_DRIVER kconfig, then VFIO_CONTAINER can instead >>>> select the IOMMUFD_DRIVER alone so long as CONFIG_IOMMUFD isn't required? I am >>>> essentially talking about: >>> >>> Not VFIO_CONTAINER, the dirty tracking code is in vfio_main: >>> >>> vfio_main.c:#include <linux/iova_bitmap.h> >>> vfio_main.c:static int vfio_device_log_read_and_clear(struct iova_bitmap *iter, >>> vfio_main.c: struct iova_bitmap *iter; >>> vfio_main.c: iter = iova_bitmap_alloc(report.iova, report.length, >>> vfio_main.c: ret = iova_bitmap_for_each(iter, device, >>> vfio_main.c: iova_bitmap_free(iter); >>> >>> And in various vfio device drivers. >>> >>> So the various drivers can select IOMMUFD_DRIVER >>> >> >> It isn't so much that type1 requires IOMMUFD, but more that it is used together >> with the core code that allows the vfio drivers to do migration. So the concern >> is if we make VFIO core depend on IOMMU that we prevent >> VFIO_CONTAINER/VFIO_GROUP to not be selected. My kconfig read was that we either >> select VFIO_GROUP or VFIO_DEVICE_CDEV but not both > > Doing it as I said is still the right thing. > > If someone has turned on one of the drivers that actually implements > dirty tracking it will turn on IOMMUFD_DRIVER and that will cause the > supporting core code to compile in the support functions. > Yeap. And as long as CONFIG_IOMMUFD_DRIVER does not select/enable CONFIG_IOMMUFD then we should be fine
