On 08/08/2025 05:09, Zhenzhong Duan wrote:
> Commit e46883204c38 ("vfio/migration: Block migration with vIOMMU")
> introduces a migration blocker when vIOMMU is enabled, because we need
> to calculate the IOVA ranges for device dirty tracking. But this is
> unnecessary for iommu dirty tracking.
>
> Limit the vfio_viommu_preset() check to those devices which use device
> dirty tracking. This allows live migration with VFIO devices which use
> iommu dirty tracking.
>
The subject of the patch is a little misleading because LM is already allowed
with VFIO devices and IOMMU dirty tracking. Yet the patch is about VMs with
vIOMMU that get this blocked due to VF device dirty tracking. I suggest instead:
vfio/migration: Allow live migration with vIOMMU without VFs using device dirty
tracking
... It's longer but I think it rings a bit more honest on what we are doing :)
> Introduce a helper vfio_device_dirty_pages_disabled() to facilicate it.
>
> Signed-off-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
This is unfortunately not enough to unblock vIOMMU migration with IOMMUs.
Have a look at the first four patches of this series:
https://github.com/jpemartins/qemu/commits/vfio-migration-viommu/
These 4 are meant do this (41d778dda00^..d27e5a5db5f4). Feel free to pick them
up. I hope to take care of the rest of the series; though I have been heavily
preempted internally that I hadn't had the time to clear this series but I think
it's finally coming to an end
The gist of these first four patches is essentially that we need to query the
dirty bitmap before unmap, and we have an extra optimization that let us simply
read the Dirty bit (without clearing it) and so the query is much faster as you
don't have a TLB flush.
I think you can replace the fourth patch with yours as yours it's much
cleaner/simpler.
Mine was specific to IOMMUFD given that perpectual dirty tracking (type1)
required forcefully enabling migration to let it go through. But I think it's ok
for both to work
Joao
