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

[Jason Gunthorpe <jgg@nvidia.com>]

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?

Jason