Re: [PULL 17/23] vfio/migration: Implement VFIO_PRECOPY_INFO_REINIT feature

[Avihai Horon <avihaih@nvidia.com>]

On 7/3/2026 12:16 PM, Philippe Mathieu-Daudé wrote:
> External email: Use caution opening links or attachments
>
>
> On 3/7/26 10:13, Avihai Horon wrote:
>>
>> On 7/3/2026 5:07 AM, Philippe Mathieu-Daudé wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> On 30/6/26 06:31, Cédric Le Goater wrote:
>>>> From: Avihai Horon <avihaih@nvidia.com>
>>>>
>>>> According to VFIO uAPI, precopy initial_bytes is considered as 
>>>> critical
>>>> data that should be transferred and loaded prior to moving to 
>>>> STOP_COPY
>>>> state to ensure precopy phase would be effective.
>>>>
>>>> As currently defined, initial_bytes can only decrease as it's being 
>>>> read
>>>> from the data fd. However, there are cases where a new chunk of
>>>> initial_bytes should be transferred during precopy.
>>>>
>>>> The new VFIO_PRECOPY_INFO_REINIT feature addresses this and allows
>>>> reporting a new value for initial_bytes regardless of any previously
>>>> reported values.
>>>>
>>>> Implement VFIO_PRECOPY_INFO_REINIT feature:
>>>> 1. Opt-in for VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 to make
>>>>     VFIO_PRECOPY_INFO_REINIT available.
>>>> 2. Request a new switchover ACK if initial_bytes increases post of a
>>>>     previous switchover ACK. This ensures the device is not moved to
>>>>     STOP_COPY before initial_bytes has reached zero again.
>>>>
>>>> Acked-by: Peter Xu <peterx@redhat.com>
>>>> Signed-off-by: Avihai Horon <avihaih@nvidia.com>
>>>> Link: 
>>>> https://lore.kernel.org/qemu-devel/20260622101214.25770-13-
>>>> avihaih@nvidia.com
>>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>>> ---
>>>>   docs/devel/migration/vfio.rst     | 14 +++++++
>>>>   hw/vfio/vfio-migration-internal.h |  1 +
>>>>   hw/vfio/migration.c               | 68 
>>>> ++++++++++++++++++++++++++++---
>>>>   hw/vfio/trace-events              |  4 +-
>>>>   4 files changed, 80 insertions(+), 7 deletions(-)
>>>
>>>
>>>> +/* Returns 1 on success, 0 if not supported and negative errno on
>>>> failure */
>>>> +static int vfio_migration_set_precopy_info_v2(VFIODevice *vbasedev)
>>>> +{
>>>> +    uint64_t buf[DIV_ROUND_UP(sizeof(struct vfio_device_feature),
>>>> +                              sizeof(uint64_t))] = {};
>>>
>>> What is the point of using uint64_t[] here?
>>
>> Since there is no data payload in this case, it's mainly for consistency
>> with other VFIO_DEVICE_FEATURE ioctl call sites.
>
> Ah, I didn't noticed. Does the VFIO_DEVICE_FEATURE ioctl expect
> the buffer to be 64-bit aligned?

Nope.
AFAIU, the 64-bit alignment is for userspace, for the data payload to be 
aligned, in case it holds some 64-bit members.

>
>>
>> Thanks.
>>
>>>
>>>> +    struct vfio_device_feature *feature = (struct
>>>> vfio_device_feature *)buf;
>>>> +
>>>> +    feature->argsz = sizeof(buf);
>>>> +    feature->flags =
>>>> +        VFIO_DEVICE_FEATURE_SET |
>>>> VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2;
>>>> +    if (ioctl(vbasedev->fd, VFIO_DEVICE_FEATURE, feature)) {
>>>> +        if (errno == ENOTTY) {
>>>> +            return 0;
>>>> +        }
>>>> +
>>>> +        return -errno;
>>>> +    }
>>>> +
>>>> +    return 1;
>>>> +}
>>>
>