Re: [PATCH v5 9/9] Documentation: Update VFIO NOIOMMU mode

[Yi Liu]

On 5/21/26 00:26, Jacob Pan wrote:
> Hi Yi,
>
> On Wed, 20 May 2026 15:20:30 +0800
> Yi Liu <yi.l.liu@xxxxxxxxx> wrote:
>
> > On 5/12/26 02:41, Jacob Pan wrote:
> > > Document the NOIOMMU mode with newly added cdev support under
> > > iommufd.
> > >
> > > Cc: Jonathan Corbet <corbet@xxxxxxx>
> > > Signed-off-by: Jacob Pan <jacob.pan@xxxxxxxxxxxxxxxxxxx>
> > > ---
> > >    Documentation/driver-api/vfio.rst | 46
> > > +++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2
> > > deletions(-)
> > >
> > > diff --git a/Documentation/driver-api/vfio.rst
> > > b/Documentation/driver-api/vfio.rst index
> > > 2a21a42c9386..d97017d80b98 100644 ---
> > > a/Documentation/driver-api/vfio.rst +++
> > > b/Documentation/driver-api/vfio.rst @@ -275,8 +275,6 @@ in a VFIO
> > > group. With CONFIG_VFIO_DEVICE_CDEV=y the user can now acquire a
> > > device fd by directly opening a character device
> > > /dev/vfio/devices/vfioX where "X" is the number allocated uniquely
> > > by VFIO for registered devices. -cdev interface does not support
> > > noiommu devices, so user should use -the legacy group interface if
> > > noiommu is wanted.
> > >    The cdev only works with IOMMUFD.  Both VFIO drivers and
> > > applications must adapt to the new cdev security model which
> > > requires using @@ -370,6 +368,50 @@ IOMMUFD IOAS/HWPT to enable
> > > userspace DMA::
> > >    	/* Other device operations as stated in "VFIO Usage
> > > Example" */
> > > +VFIO NOIOMMU mode
> > > +-------------------------------------------------------------------------------
> > > +VFIO also supports a no-IOMMU mode, intended for usages where
> > > unsafe DMA can +be performed by userspace drivers w/o physical
> > > IOMMU protection. This mode +is controlled by the parameter:
> > > +
> > > +/sys/module/vfio/parameters/enable_unsafe_noiommu_mode
> > > +
> > > +Upon enabling this mode, with an assigned device, the user will be
> > > presented +with a VFIO group and device file, e.g.::
> > > +
> > > +  /dev/vfio/
> > > +  |-- devices
> > > +  |   `-- noiommu-vfio0	/* VFIO device cdev */
> > > +  |-- noiommu-0		/* VFIO group */
> > > +  `-- vfio
> >
> > how about noiommu-vfioX and noiommu-Y? Just want to deliver the
> > message that the two number is not 100% identical.
> good point.
>
> > > +The capabilities vary depending on the device programming
> > > interface and kernel +configuration used. The following table
> > > summarizes the differences: +
> > > ++-------------------+---------------------+----------------------+
> > > +| Feature           | VFIO group          | VFIO device cdev     |
> > > ++===================+=====================+======================+
> > > +| VFIO device UAPI  | Yes                 | Yes                  |
> > > ++-------------------+---------------------+----------------------+
> > > +| VFIO container    | No                  | No                   |
> > > ++-------------------+---------------------+----------------------+
> > > +| IOMMUFD IOAS      | No                  | Yes*                 |
> > > ++-------------------+---------------------+----------------------+
> > > +
> >
> > not quite the above table. Why 'VFIO container' is "No" for VFIO
> > group?
> I meant VFIO group interface has no access to VFIO container UAPIs,
> such as DMA MAP/UNMAP.
>
> how about I will add the following:
>
>   The capabilities vary depending on the device programming interface and kernel
> -configuration used. The following table summarizes the differences:
> +configuration used. The following table summarizes the differences ("Yes" means
> +the UAPI is accessible and functional in noiommu mode, "No" means the UAPI is
> +not supported):

I see. this helps a lot. :)

> > > +Note that the VFIO container case includes IOMMUFD provided VFIO
> > > compatibility +interfaces when either CONFIG_VFIO_CONTAINER or
> > > CONFIG_IOMMUFD_VFIO_CONTAINER is +enabled.
> > > +
> > > +* IOMMUFD UAPI is available for VFIO device cdev to pin and map
> > > user memory with
> > > +  the ability to retrieve physical addresses for DMA command
> > > submission. +
> > > +A new IOMMUFD ioctl IOMMU_IOAS_NOIOMMU_GET_PA is added to retrieve
> > > the physical +address for a given IOVA. Although there is no
> > > physical DMA remapping hardware, +IOMMU_IOAS_MAP_FIXED_IOVA is
> > > still used to establish IOVA-to-PA mappings in the +software page
> > > table for later IOMMU_IOAS_NOIOMMU_GET_PA lookups.
> > > +tools/testing/selftests/vfio/vfio_iommufd_noiommu_test.c provides
> > > an example of +using this ioctl in no-IOMMU mode. +
> > >    VFIO User API
> > >    -------------------------------------------------------------------------------
> > >