Re: [PATCH V4 10/10] Documentation: Update VFIO NOIOMMU mode

[Jacob Pan <jacob.pan@linux.microsoft.com>]

Hi Yi,

On Tue, 28 Apr 2026 15:46:02 +0800
Yi Liu <yi.l.liu@intel.com> wrote:

> On 4/15/26 05:14, 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 | 45
> > +++++++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2
> > deletions(-)
> > 
> > diff --git a/Documentation/driver-api/vfio.rst
> > b/Documentation/driver-api/vfio.rst index
> > 2a21a42c9386..da6f77414c3b 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,49 @@ 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
> > +
> > +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*                 |
> > ++-------------------+---------------------+----------------------+
> > +
> > +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_GET_PA is added to retrieve the
> > physical address +for a given user virtual address. Note that
> > IOMMU_IOAS_MAP_FIXED_IOVA flag is +ignored in no-IOMMU mode since
> > there is no physical DMA remapping hardware.  
> 
> not quite get this. Does it mean the the iova field is not used when
> invoking IOMMU_IOAS_MAP ioctl? Hence the iova will be allocated by
> iommufd and returned to userspace? Also, how does kernel know it
> should ignore IOMMU_IOAS_MAP_FIXED_IOVA flag?
> 

Good question. Let me clarify — I should reword this in the cover letter.

The IOMMU_IOAS_MAP_FIXED_IOVA flag is NOT silently ignored by the kernel.
Userspace can still pass it as with normal IOMMU mode, otherwise
IOPT_ALLOC_IOVA kicks in and IOMMUFD allocates an IOVA from the allowed
range.

What I meant is that in no-IOMMU mode, the IOVA itself has no physical
significance — there is no DMA remapping hardware programming the
IOVA→PA translation. The IOVA is simply used as a key in the software
IO page table (IOMMU_PT_AMDV1 backed) to track the pinned pages and
their physical addresses.

So from the userspace API perspective, the flow is identical:

  1. IOMMU_IOAS_MAP with FIXED_IOVA flag and user VA → pins pages,
  stores PA in the SW page table at the given IOVA
  2. IOMMU_IOAS_GET_PA with that IOVA → returns the physical address
  for DMA command submission

The kernel doesn't need special logic to "know" it should ignore
anything — the same iopt_map code path runs; it's just that the
backing domain is iommufd_noiommu_ops (a software page table) rather
than a hardware IOMMU domain.

The user is assumed to know how to use the special IOVA as the unsafe
noiommu mode is enabled by the user.

I'll fix the misleading wording in the next version.