On Fri, 13 Oct 2023 18:23:09 +0100 Joao Martins <joao.m.martins@xxxxxxxxxx> 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: > >>>>> Both VFIO and IOMMUFD will need iova bitmap for storing dirties and walking > >>>>> the user bitmaps, so move to the common dependency into IOMMU core. IOMMUFD > >>>>> can't exactly host it given that VFIO dirty tracking can be used without > >>>>> IOMMUFD. > >>>> > >>>> Hum, this seems strange. Why not just make those VFIO drivers depends > >>>> on iommufd? That seems harmless to me. > >>>> > >>> > >>> IF you and Alex are OK with it then I can move to IOMMUFD. It's only strange in that we don't actually have a hard dependency on IOMMUFD currently and won't until we remove container support, which is some ways down the road. Ultimately we expect to get to the same place, so I don't have a particular issue with it. > >>>> However, I think the real issue is that iommu drivers need to use this > >>>> API too for their part? > >>>> > >>> > >>> Exactly. > >>> > >> > >> My other concern into moving to IOMMUFD instead of core was VFIO_IOMMU_TYPE1, > >> and if we always make it depend on IOMMUFD then we can't have what is today > >> something supported because of VFIO_IOMMU_TYPE1 stuff with migration drivers > >> (i.e. vfio-iommu-type1 with the live migration stuff). > > > > I plan to remove the live migration stuff from vfio-iommu-type1, it is > > all dead code now. > > > > I wasn't referring to the type1 dirty tracking stuff -- I was referring the > stuff related to vfio devices, used *together* with type1 (for DMA map/unmap). > > >> 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 That's not true. We can have both. In fact we rely on having both to support a smooth transition to the cdev interface. Thanks, Alex
