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

[Yi Liu <yi.l.liu@intel.com>]

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@intel.com> 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@lwn.net>
>>> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com>
>>> ---
>>>    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
>>>    -------------------------------------------------------------------------------
>>>      
>