Re: [RFC v4 01/21] vfio-user: introduce vfio-user protocol specification

[John Johnson]

> On Mar 9, 2022, at 2:34 PM, Alex Williamson <alex.williamson@redhat.com> 
> wrote:
> 
>> 
>> +
>> +VFIO region info type cap
>> +"""""""""""""""""""""""""
>> +
>> +The VFIO region info type is defined in ``<linux/vfio.h>``
>> +(``struct vfio_region_info_cap_type``).
>> +
>> ++---------+--------+------+
>> +| Name    | Offset | Size |
>> ++=========+========+======+
>> +| type    | 0      | 4    |
>> ++---------+--------+------+
>> +| subtype | 4      | 4    |
>> ++---------+--------+------+
>> +
>> +The only device-specific region type and subtype supported by vfio-user is
>> +``VFIO_REGION_TYPE_MIGRATION`` (3) and ``VFIO_REGION_SUBTYPE_MIGRATION`` 
>> (1).
> 
> These should be considered deprecated from the kernel interface.  I
> hope there are plans for vfio-user to adopt the new interface that's
> currently available in linux-next and intended for v5.18.
> 


        We will follow the interfaces that QEMU uses.  Do you have an idea
when the VFIO v2 changes will be pulled into QEMU?  Will the v2 code be
experimental like v1 was?



> ...
>> +Unused VFIO ``ioctl()`` commands
>> +--------------------------------
>> +
>> +The following VFIO commands do not have an equivalent vfio-user command:
>> +
>> +* ``VFIO_GET_API_VERSION``
>> +* ``VFIO_CHECK_EXTENSION``
>> +* ``VFIO_SET_IOMMU``
>> +* ``VFIO_GROUP_GET_STATUS``
>> +* ``VFIO_GROUP_SET_CONTAINER``
>> +* ``VFIO_GROUP_UNSET_CONTAINER``
>> +* ``VFIO_GROUP_GET_DEVICE_FD``
>> +* ``VFIO_IOMMU_GET_INFO``
>> +
>> +However, once support for live migration for VFIO devices is finalized some
>> +of the above commands may have to be handled by the client in their
>> +corresponding vfio-user form. This will be addressed in a future protocol
>> +version.
> 
> As above, I'd go ahead and drop the migration region interface support,
> it's being removed from the kernel.  Dirty page handling might also be
> something you want to pull back on as we're expecting in-kernel vfio to
> essentially deprecate its iommu backends in favor of a new shared
> userspace iommufd interface.  We expect to have backwards compatibility
> via that interface, but as QEMU migration support for vfio-pci devices
> is experimental and there are desires not to consolidate dirty page
> tracking behind the iommu interface in the new model, it's not clear if
> the kernel will continue to expose the current dirty page tracking.
> 
> AIUI, we're expecting to see patches officially proposing the iommufd
> interface in the kernel "soon".  Thanks,
> 


        I’m not very concerned about which host kernel drivers QEMU will
interact with, as vfio-user doesn’t talk to any of them.  I am interested
in the data structures being used.  Will they remain dirty bitmap based,
or is a different structure being entertained?

                                                                JJ