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/[email protected]/
Zhengzhong's :
* [PATCH rfcv2 00/18] Check and sync host IOMMU cap/ecap with vIOMMU
https://lore.kernel.org/qemu-devel/[email protected]/
Eric's :
* [RFC 0/7] VIRTIO-IOMMU/VFIO: Fix host iommu geometry handling for hotplugged
devices
https://lore.kernel.org/qemu-devel/[email protected]/
Steve's:
* [PATCH V3 00/13] allow cpr-reboot for vfio
https://lore.kernel.org/qemu-devel/[email protected]/
Mine, which should be an RFC :
* [PATCH 00/14] migration: Improve error reporting
https://lore.kernel.org/qemu-devel/[email protected]/
Anything else ?
Thanks,
C.
