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

From: Jason Gunthorpe

Date: Mon Jul 06 2026 - 15:54:15 EST


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