On 15/02/2023 14:43, Juan Quintela wrote:
External email: Use caution opening links or attachments
Avihai Horon <avih...@nvidia.com> wrote:
Currently, if IOMMU of a VFIO container doesn't support dirty page
tracking, migration is blocked. This is because a DMA-able VFIO device
can dirty RAM pages without updating QEMU about it, thus breaking the
migration.
However, this doesn't mean that migration can't be done at all.
In such case, allow migration and let QEMU VFIO code mark all pages
dirty.
This guarantees that all pages that might have gotten dirty are reported
back, and thus guarantees a valid migration even without VFIO IOMMU
dirty tracking support.
The motivation for this patch is the introduction of iommufd [1].
iommufd can directly implement the /dev/vfio/vfio container IOCTLs by
mapping them into its internal ops, allowing the usage of these IOCTLs
over iommufd. However, VFIO IOMMU dirty tracking is not supported by
this VFIO compatibility API.
This patch will allow migration by hosts that use the VFIO compatibility
API and prevent migration regressions caused by the lack of VFIO IOMMU
dirty tracking support.
[1]
https://lore.kernel.org/kvm/0-v6-a196d26f289e+11787-iommufd_...@nvidia.com/
Signed-off-by: Avihai Horon <avih...@nvidia.com>
Reviewed-by: Cédric Le Goater <c...@redhat.com>
Reviewed-by: Juan Quintela <quint...@redhat.com>
I know why you are doing this.
But I think this should print a warning, error, somewhere.
IMHO, I'm not sure it's really necessary.
To enable VFIO migration the user must explicitly set x-enable-migration=on.
I guess in this case the user is well aware of the dirty tracking
capabilities the VFIO device has or doesn't have.
So I don't think adding this error/warning will help much.
Thanks.
You are just dirtying all pages each time we arrive here.
Even calling the featura "experimental" is an understatement.
Later, Juan.
