Re: [PATCH 4/9] vfio/migration: Skip pre-copy if dirty page tracking is not supported

[Alex Williamson]

On Tue, 17 May 2022 14:39:37 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Tue, May 17, 2022 at 11:22:32AM -0600, Alex Williamson wrote:
> 
> > > > It seems like a better solution would be to expose to management
> > > > tools that the VM contains a device that does not support the
> > > > pre-copy phase so that downtime expectations can be adjusted.    
> > > 
> > > I don't expect this to be a real use case though..
> > > 
> > > Remember, you asked for this patch when you wanted qemu to have good
> > > behavior when kernel support for legacy dirty tracking is removed
> > > before we merge v2 support.  
> > 
> > Is wanting good behavior a controversial point?  Did we define this as
> > the desired good behavior?  Ref?    
> 
> As I said, this was intended as a NOP, which is what I thought we
> agreed to. Missing the SLA checking that existed before seems like
> something to fix in this patch.

But even if we have the SLA check, how does a management tool know that
pre-copy will be skipped and that the downtime needs to account for
that?  The current solution is obviously non-optimal, it was mainly
meant for backwards compatibility, but this seems like a fail faster
solution, with less useless work, but also providing less indication
how to configure the migration to succeed.

> This is the discussion thread:
> 
> https://lore.kernel.org/kvm/20220324231159.GA11336@nvidia.com/
> 
>  "I guess I was assuming that enabling v2 migration in QEMU was dependent
>   on the existing type1 dirty tracking because it's the only means we
>   have to tell QEMU that all memory is perpetually dirty when we have a
>   DMA device.  Is that not correct?"

Doesn't sound like me asking for this patch so much as trying to figure
out how to support migration without DMA dirty tracking, and after the
above comment was a concern whether we lock ourselves into a dirty
tracking requirement in the iommufd type1 compatibility interface if we
rely on this type1 feature.  You had spit-balled that QEMU could skip
pre-copy, but this all needs to be vetted with migration folks and
management tools.

> The only point was to prepare qemu for kernel's that don't support the
> legacy dirty tracking API but do have a v2 migration interface. IIRC
> something undesired happens if you do that right now.

Per this patch, the container requires dirty tracking or we add a
blocker and can't migrate the device.
 
> We could also just dirty all memory in qemu and keep it exactly the
> same so every SLA detail works. Or completely block pre-copy based
> flows.
> 
> It it not intended to be a useful configuration, this is just covering
> off backwards compat issues - so I'm not keen to do a bunch of
> management work to support it.

Are we then deemphasizing the vfio compatibility support in iommufd?
If we really don't want to put effort towards backwards compatibility,
should migration support only be enabled with native iommufd support?
Thanks,

Alex