Re: [PATCH v3 02/19] vfio: Move iova_bitmap into iommu core

Joao Martins
2023-10-13T17:32:59Z

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