Documentation/userspace-api/iommufd.rst

1 .. SPDX-License-Identifier: GPL-2.0+
20 I/O page tables for all IOMMUs, with room in the design to add non-generic
31 --------------------
35 - IOMMUFD_OBJ_IOAS, representing an I/O address space (IOAS), allowing map/unmap
41 - IOMMUFD_OBJ_DEVICE, representing a device that is bound to iommufd by an
44 - IOMMUFD_OBJ_HW_PAGETABLE, representing an actual hardware I/O page table
50 All user-visible objects are destroyed via the IOMMU_DESTROY uAPI.
52 The diagram below shows relationship between user-visible objects and kernel
68  | |      IOAS       |<--|            |<------|          | |
82            |------------>|iommu_domain|    |struct device|
117 --------------------
121 - iommufd_ioas for IOMMUFD_OBJ_IOAS.
122 - iommufd_device for IOMMUFD_OBJ_DEVICE.
123 - iommufd_hw_pagetable for IOMMUFD_OBJ_HW_PAGETABLE.
127 - Automatic domain - refers to an iommu domain created automatically when
131 - Manual domain - refers to an iommu domain designated by the user as the
136 - In-kernel user - refers to something like a VFIO mdev that is using the
145 - struct io_pagetable holding the IOVA map
146 - struct iopt_area's representing populated portions of IOVA
147 - struct iopt_pages representing the storage of PFNs
148 - struct iommu_domain representing the IO page table in the IOMMU
149 - struct iopt_pages_access representing in-kernel users of PFNs
150 - struct xarray pinned_pfns holding a list of pages pinned by in-kernel users
158 on what domains are present and what kinds of in-kernel "software access" users
164 Multiple io_pagetable-s, through their iopt_area-s, can share a single
165 iopt_pages which avoids multi-pinning and double accounting of page
168 iommufd_ioas is shareable between subsystems, e.g. VFIO and VDPA, as long as
169 devices managed by different subsystems are bound to a same iommufd.
174 .. kernel-doc:: include/uapi/linux/iommufd.h
179 The IOMMUFD kAPI is device-centric with group-related tricks managed behind the
181 device-centric uAPI for connecting its device to an iommufd, instead of
184 .. kernel-doc:: drivers/iommu/iommufd/device.c
187 .. kernel-doc:: drivers/iommu/iommufd/main.c
191 ----------------
201 The second approach directly extends VFIO to support a new set of device-centric
206 Currently both approaches are still work-in-progress.
214 Currently IOMMUFD supports only kernel-managed I/O page table, similar to VFIO
217  - Binding iommu_domain's to PASID/SSID
218  - Userspace page tables, for ARM, x86 and S390
219  - Kernel bypass'd invalidation of user page tables
220  - Re-use of the KVM page table in the IOMMU
221  - Dirty page tracking in the IOMMU
222  - Runtime Increase/Decrease of IOPTE size
223  - PRI support with faults resolved in userspace