Re: [PATCH RFCv2 0/8] vfio/iommufd: IOMMUFD Dirty Tracking

["Cédric Le Goater" <clg@redhat.com>]

Hello Joao,

On 2/13/24 12:59, Joao Martins wrote:
> On 12/02/2024 13:56, Joao Martins wrote:
>> This small series adds support for Dirty Tracking in IOMMUFD backend.
>> The sole reason I still made it RFC is because of the second patch,
>> where we are implementing user-managed auto domains.
>>
>> In essence it is quite similar to the original IOMMUFD series where we
>> would allocate a HWPT, until we switched later on into a IOAS attach.
>> Patch 2 goes into more detail, but the gist is that there's two modes of
>> using IOMMUFD and by keep using kernel managed auto domains we would end
>> up duplicating the same flags we have in HWPT but into the VFIO IOAS
>> attach. While it is true that just adding a flag is simpler, it also
>> creates duplication and motivates duplicate what hwpt-alloc already has.
>> But there's a chance I have the wrong expectation here, so any feedback
>> welcome.
>>
>> The series is divided into:
>>
>> * Patch 1: Adds a simple helper to get device capabilities;
>>
>> * Patches 2 - 5: IOMMUFD backend support for dirty tracking;
>>
>> The workflow is relatively simple:
>>
>> 1) Probe device and allow dirty tracking in the HWPT
>> 2) Toggling dirty tracking on/off
>> 3) Read-and-clear of Dirty IOVAs
>>
>> The heuristics selected for (1) were to enable it *if* device supports
>> migration but doesn't support VF dirty tracking or IOMMU dirty tracking
>> is supported. The latter is for the hotplug case where we can add a device
>> without a tracker and thus still support migration.
>>
>> The unmap case is deferred until further vIOMMU support with migration
>> is added[3] which will then introduce the usage of
>> IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR in GET_DIRTY_BITMAP ioctl in the
>> dma unmap bitmap flow.
>>
>> * Patches 6-8: Add disabling of hugepages to allow tracking at base
>> page; avoid blocking live migration where there's no VF dirty
>> tracker, considering that we have IOMMU dirty tracking. And allow
>> disabling VF dirty tracker via qemu command line.
>>
>> This series builds on top of Zhengzhong series[0], but only requires the
>> first 9 patches i.e. up to ("vfio/pci: Initialize host iommu device
>> instance after attachment")[1] that are more generic IOMMUFD device
>> plumbing, and doesn't require the nesting counterpart.
>>
> I need to add that this series doesn't *need* to be based on Zhengzhong series.
> Though given that he is consolidating how an IOMMUFD device info is represented
> it felt the correct thing to do. For dirty tracking we mainly need the
> dev_id/iommufd available when we are going to attach, that's it.
> 
> I've pushed this series version that doesn't have such dependency, let me know
> if you want me to pursue this version instead going forward:
> 
> https://github.com/jpemartins/qemu/commits/iommufd-v5.nodeps

I feel I have lost track of all the different patchsets.

To recap, there is yours :

* vfio/iommufd: IOMMUFD Dirty Tracking
   https://lore.kernel.org/qemu-devel/20240212135643.5858-1-joao.m.martins@oracle.com/

Zhengzhong's :

* [PATCH rfcv2 00/18] Check and sync host IOMMU cap/ecap with vIOMMU
   https://lore.kernel.org/qemu-devel/20240201072818.327930-1-zhenzhong.duan@intel.com/

Eric's :

* [RFC 0/7] VIRTIO-IOMMU/VFIO: Fix host iommu geometry handling for hotplugged devices
   https://lore.kernel.org/qemu-devel/20240117080414.316890-1-eric.auger@redhat.com/

Steve's:

* [PATCH V3 00/13] allow cpr-reboot for vfio
   https://lore.kernel.org/qemu-devel/1707418446-134863-1-git-send-email-steven.sistare@oracle.com/

Mine, which should be an RFC :

* [PATCH 00/14] migration: Improve error reporting
   https://lore.kernel.org/qemu-devel/20240207133347.1115903-1-clg@redhat.com/

Anything else ?

Thanks,

C.