[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/14] vfio/migration: Implement VFIO migration protocol v
|
From: |
Jason Gunthorpe |
|
Subject: |
Re: [PATCH v5 00/14] vfio/migration: Implement VFIO migration protocol v2 |
|
Date: |
Fri, 6 Jan 2023 19:45:13 -0400 |
On Fri, Jan 06, 2023 at 04:36:09PM -0700, Alex Williamson wrote:
> Missing from the series is the all important question of what happens
> to "x-enable-migration" now. We have two in-kernel drivers supporting
> v2 migration, so while hardware and firmware may still be difficult to
> bring together, it does seem possible for the upstream community to
> test and maintain this.
My post-break memory is a bit hazy, but don't we still need a qemu
series for the new dirty tracking uAPI? I suggest that is the right
spot to declare victory on this, as it is actually production usable
and testable.
I'm also hopeful we can see the system iommu dirty tracking
> To declare this supported and not to impose any additional requirements
> on management tools, I think migration needs to be enabled by default
> for devices that support it.
At least for mlx5 there will be a switch that causes the VF to not
support migration, and that will be probably be the default.
> Is there any utility to keeping around
> some sort of device option to force it ON/OFF?
I think not at the qemu, level. Even for testing purposes it is easy
to disable live migration by not loading the valiant vfio driver.
Jason