Re: [PATCH v10 0/6] iommufd: Enable noiommu mode for cdev

[Alex Williamson <alex@shazbot.org>]

On Mon, 6 Jul 2026 16:54:03 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Mon, Jul 06, 2026 at 11:48:28AM -0700, Jacob Pan wrote:
> > VFIO's unsafe_noiommu_mode has long provided a way for userspace drivers
> > to operate on platforms lacking a hardware IOMMU. Today, IOMMUFD also
> > supports No-IOMMU mode for group-based devices under vfio_compat mode.
> > However, IOMMUFD's native character device (cdev) does not yet support
> > No-IOMMU mode, which is the purpose of this patch.
> > 
> > In summary, we have:
> > 
> > |-------------------------+------+---------------|
> > | Device access mode      | VFIO | IOMMUFD       |
> > |-------------------------+------+---------------|
> > | group /dev/vfio/$GROUP  | Yes  | Yes           |
> > |-------------------------+------+---------------|
> > | cdev /dev/vfio/devices/ | No   | This patch    |
> > |-------------------------+------+---------------|
> > 
> > Beyond enabling cdev for IOMMUFD, this patch also addresses the following
> > deficiencies in the current No-IOMMU mode suggested by Jason[1]:
> > - Devices operating under No-IOMMU mode are limited to device-level UAPI
> >   access, without container or IOAS-level capabilities. Consequently,
> >   user-space drivers lack structured mechanisms for page pinning and often
> >   resort to mlock(), which is less robust than pin_user_pages() used for
> >   devices backed by a physical IOMMU. For example, mlock() does not prevent
> >   page migration.
> > - There is no architectural mechanism for obtaining physical addresses for
> >   DMA. As a workaround, user-space drivers frequently rely on /proc/pagemap
> >   tricks or hardcoded values.
> > 
> > By allowing noiommu device access to IOMMUFD IOAS and HWPT objects, this
> > patch brings No-IOMMU mode closer to full citizenship within the IOMMU
> > subsystem. In addition to addressing the two deficiencies mentioned above,
> > the expectation is that it will also enable No-IOMMU devices to seamlessly
> > participate in live update sessions via KHO [2].
> > 
> > Furthermore, these devices will use the IOMMUFD-based ownership checking model for
> > VFIO_DEVICE_PCI_HOT_RESET, eliminating the need for an iommufd_access object
> > as required in a previous attempt [3].
> > 
> > ChangeLog:
> > v10:
> >   - Rebased to v7.2-rc2, no intended code change  
> 
> My impression is we are good on this now, right? I would like to pick
> it up?

There are a couple Sashiko findings.  The PAGE_SIZE issue seems like a
false positive.  The AMD based page tables necessarily expose 4K, but
pinning is obviously at PAGE_SIZE, so returning multiples of PAGE_SIZE
is arguably correct.

The PASID issue seems more like a uAPI hygiene question, and it might
be the correct answer to return error for values other than
IOMMU_NO_PASID.  Your call.

Fine otherwise from a vfio perspective.  Thanks,

Alex