Re: [PATCH v11 08/11] vfio/migration: Implement VFIO migration protocol v2

[Peter Xu <peterx@redhat.com>]

On Thu, Sep 05, 2024 at 07:07:28PM +0300, Avihai Horon wrote:
> > So I wonder why stop-size can change from a driver, and whether that can be
> > reported in a more predictable fashion.  Otherwise I see little point in
> > providing both stop-size and precopy-size, otherwise we'll always add them
> > up into VFIO's total pending-size.  The line on provision which data falls
> > into which bucket doesn't seem to be clear to me.
> 
> Stopcopy-size is reported by VFIO_DEVICE_FEATURE_MIG_DATA_SIZE ioctl, which
> states that this is "[...] the estimated data length that will be required
> to complete stop copy".
> So by this definition, stopcopy-size can change during precopy (it can also
> change if device resources are created or destroyed).
> 
> Precopy-size is reported by VFIO_MIG_GET_PRECOPY_INFO ioctl, which states
> that this is "[...] estimates of data available from the device during the
> PRE_COPY states".
> 
> Maybe the confusion was caused by this line in vfio_state_pending_exact():
>     *must_precopy += migration->precopy_init_size +
> migration->precopy_dirty_size;
> 
> Which I think should be removed, as stopcopy-size should already cover
> precopy data.

Would you please help double check on the kernel drivers' side?  If that's
true I agree that should be dropped.

Does it also mean then that the currently reported stop-size - precopy-size
will be very close to the constant non-iterable data size?  If so, is it
cache-able?  It doesn't need to be 100% accurate as the ioctls are not
atomic, but still if it's mostly usable (again, will need you all to help
justify that..) as that then it looks like we have some way to report that
without the concern you raised before.

Thanks,

-- 
Peter Xu