[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v4 01/21] vfio-user: introduce vfio-user protocol specification
From: |
Alex Williamson |
Subject: |
Re: [RFC v4 01/21] vfio-user: introduce vfio-user protocol specification |
Date: |
Tue, 15 Mar 2022 16:28:17 -0600 |
On Tue, 15 Mar 2022 21:43:15 +0000
Thanos Makatos <thanos.makatos@nutanix.com> wrote:
> > -----Original Message-----
> > From: Qemu-devel <qemu-devel-
> > bounces+thanos.makatos=nutanix.com@nongnu.org> On Behalf Of Alex
> > Williamson
> > Sent: 09 March 2022 22:35
> > To: John Johnson <john.g.johnson@oracle.com>
> > Cc: qemu-devel@nongnu.org
> > Subject: Re: [RFC v4 01/21] vfio-user: introduce vfio-user protocol
> > specification
> >
> > On Tue, 11 Jan 2022 16:43:37 -0800
> > John Johnson <john.g.johnson@oracle.com> wrote:
> > > +VFIO region info cap sparse mmap
> > > +""""""""""""""""""""""""""""""""
> > > +
> > > ++----------+--------+------+
> > > +| Name | Offset | Size |
> > > ++==========+========+======+
> > > +| nr_areas | 0 | 4 |
> > > ++----------+--------+------+
> > > +| reserved | 4 | 4 |
> > > ++----------+--------+------+
> > > +| offset | 8 | 8 |
> > > ++----------+--------+------+
> > > +| size | 16 | 9 |
> > > ++----------+--------+------+
> >
> > Typo, I'm pretty sure size isn't 9 bytes.
> >
> > > +| ... | | |
> > > ++----------+--------+------+
> > > +
> > > +* *nr_areas* is the number of sparse mmap areas in the region.
> > > +* *offset* and size describe a single area that can be mapped by the
> > > client.
> > > + There will be *nr_areas* pairs of offset and size. The offset will be
> > > added to
> > > + the base offset given in the ``VFIO_USER_DEVICE_GET_REGION_INFO`` to
> > form the
> > > + offset argument of the subsequent mmap() call.
> > > +
> > > +The VFIO sparse mmap area is defined in ``<linux/vfio.h>`` (``struct
> > > +vfio_region_info_cap_sparse_mmap``).
> > > +
> > > +VFIO region type cap header
> > > +"""""""""""""""""""""""""""
> > > +
> > > ++------------------+---------------------------+
> > > +| Name | Value |
> > > ++==================+===========================+
> > > +| id | VFIO_REGION_INFO_CAP_TYPE |
> > > ++------------------+---------------------------+
> > > +| version | 0x1 |
> > > ++------------------+---------------------------+
> > > +| next | <next> |
> > > ++------------------+---------------------------+
> > > +| region info type | VFIO region info type |
> > > ++------------------+---------------------------+
> > > +
> > > +This capability is defined when a region is specific to the device.
> > > +
> > > +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.
> >
> > ...
> > > +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,
>
> Are you referring to the "[RFC v2] /dev/iommu uAPI proposal" work
> (https://lkml.org/lkml/2021/7/9/89)?
There's a more recent proposal here:
https://lore.kernel.org/all/20210919063848.1476776-1-yi.l.liu@intel.com/
But I suspect based on discussions that it's evolved quite a lot since
then. Based on various test robot reports, I gather the current
pre-release is tracking in Yi's tree here:
https://github.com/luxis1999/iommufd
Thanks,
Alex