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

[Jacob Pan]

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):

> > +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
> >   -------------------------------------------------------------------------------
> >