Lines Matching +full:iommu +full:- +full:parent
1 .. SPDX-License-Identifier: GPL-2.0+
13 IOMMUFD is the user API to control the IOMMU subsystem as it relates to managing
16 drivers are eventually expected to deprecate any internal IOMMU logic
20 I/O page tables for all IOMMUs, with room in the design to add non-generic
24 small letter (iommufd) refers to the file descriptors created via /dev/iommu for
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_HWPT_PAGING, representing an actual hardware I/O page table
45 (i.e. a single struct iommu_domain) managed by the iommu driver. "PAGING"
48 feature flag. This can be either an UNMANAGED stage-1 domain for a device
49 running in the user space, or a nesting parent stage-2 domain for mappings
50 from guest-level physical addresses to host-level physical addresses.
55 - IOMMUFD_OBJ_HWPT_NESTED, representing an actual hardware I/O page table
59 IOMMU_DOMAIN_NESTED. This must be a stage-1 domain for a device running in
60 the user space (e.g. in a guest VM enabling the IOMMU nested translation
61 feature.) As such, it must be created with a given nesting parent stage-2
62 domain to associate to. This nested stage-1 page table managed by the user
63 space usually has mappings from guest-level I/O virtual addresses to guest-
66 - IOMMUFD_OBJ_VIOMMU, representing a slice of the physical IOMMU instance,
67 passed to or shared with a VM. It may be some HW-accelerated virtualization
70 * Security namespace for guest owned ID, e.g. guest-controlled cache tags
71 * Non-device-affiliated event reporting, e.g. invalidation queue errors
72 * Access to a sharable nesting parent pagetable across physical IOMMUs
78 Such a vIOMMU object generally has the access to a nesting parent pagetable
79 to support some HW-accelerated virtualization features. So, a vIOMMU object
80 must be created given a nesting parent HWPT_PAGING object, and then it would
86 The name "vIOMMU" isn't necessarily identical to a virtualized IOMMU in a
87 VM. A VM can have one giant virtualized IOMMU running on a machine having
89 or configurations from this single virtualized IOMMU instance to multiple
92 IOMMU, not necessarily of a virtualized IOMMU. For VMMs that want the full
95 passed-through devices would be connected to their own virtualized IOMMUs
99 - IOMMUFD_OBJ_VDEVICE, representing a virtual device for an IOMMUFD_OBJ_DEVICE
104 e.g. vSID of ARM SMMUv3, vDeviceID of AMD IOMMU, and vRID of Intel VT-d to a
112 All user-visible objects are destroyed via the IOMMU_DESTROY uAPI.
114 The diagrams below show relationships between user-visible objects and kernel
124 | | IOAS |<---| HWPT_PAGING |<---------------------| DEVICE | |
131 |------------>|iommu_domain|<-----------------------|device|
140 | | IOAS |<---| HWPT_PAGING |<---| HWPT_NESTED |<--| DEVICE | |
147 |------------>|iommu_domain|<----|iommu_domain|<----|device|
156 | |----------------| vIOMMU |<---| vDEVICE |<----| |
162 | | | IOAS |<---|(HWPT_PAGING)|<---| HWPT_NESTED |<--| DEVICE | |
169 |iommu_device| |------>|iommu_domain|<----|iommu_domain|<----|device|
174 expose interfaces that are specific to single IOMMU drivers. All operations
199 allocates a nesting parent HWPT_PAGING if the IOMMU_HWPT_ALLOC_NEST_PARENT
204 nesting parent HWPT_PAGING via @pt_id to associate the new HWPT_NESTED object
206 must be a nesting parent manually allocated via the same uAPI previously with
208 allocation will be further validated by the IOMMU driver to ensure that the
209 nesting parent domain and the nested domain being allocated are compatible.
211 and iommu_domains. Once this completes the device could do DMA via a 2-stage
213 can be allocated by (and then associated to) the same nesting parent.
222 uAPI, provided a dev_id (for the device's physical IOMMU to back the vIOMMU)
223 and an hwpt_id (to associate the vIOMMU to a nesting parent HWPT_PAGING). The
225 struct device is behind. And an IOMMU driver can implement a viommu_alloc op
226 to allocate its own vIOMMU data structure embedding the core-level structure
227 iommufd_viommu and some driver-specific data. If necessary, the driver can
231 as a nesting parent object to allocate an HWPT_NESTED object described above.
236 two parent objects. Another @virt_id will be also set via the uAPI providing
238 vIOMMU. If necessary, the IOMMU driver may choose to implement a vdevce_alloc
246 --------------------
250 - iommufd_ioas for IOMMUFD_OBJ_IOAS.
251 - iommufd_device for IOMMUFD_OBJ_DEVICE.
252 - iommufd_hwpt_paging for IOMMUFD_OBJ_HWPT_PAGING.
253 - iommufd_hwpt_nested for IOMMUFD_OBJ_HWPT_NESTED.
254 - iommufd_viommu for IOMMUFD_OBJ_VIOMMU.
255 - iommufd_vdevice for IOMMUFD_OBJ_VDEVICE.
259 - Automatic domain - refers to an iommu domain created automatically when
263 - Manual domain - refers to an iommu domain designated by the user as the
268 - In-kernel user - refers to something like a VFIO mdev that is using the
277 - struct io_pagetable holding the IOVA map
278 - struct iopt_area's representing populated portions of IOVA
279 - struct iopt_pages representing the storage of PFNs
280 - struct iommu_domain representing the IO page table in the IOMMU
281 - struct iopt_pages_access representing in-kernel users of PFNs
282 - struct xarray pinned_pfns holding a list of pages pinned by in-kernel users
290 on what domains are present and what kinds of in-kernel "software access" users
296 Multiple io_pagetable-s, through their iopt_area-s, can share a single
297 iopt_pages which avoids multi-pinning and double accounting of page
306 .. kernel-doc:: include/uapi/linux/iommufd.h
311 The IOMMUFD kAPI is device-centric with group-related tricks managed behind the
313 device-centric uAPI for connecting its device to an iommufd, instead of
316 .. kernel-doc:: drivers/iommu/iommufd/device.c
319 .. kernel-doc:: drivers/iommu/iommufd/main.c
323 ----------------
333 The second approach directly extends VFIO to support a new set of device-centric
338 Currently both approaches are still work-in-progress.
346 Currently IOMMUFD supports only kernel-managed I/O page table, similar to VFIO
349 - Binding iommu_domain's to PASID/SSID
350 - Userspace page tables, for ARM, x86 and S390
351 - Kernel bypass'd invalidation of user page tables
352 - Re-use of the KVM page table in the IOMMU
353 - Dirty page tracking in the IOMMU
354 - Runtime Increase/Decrease of IOPTE size
355 - PRI support with faults resolved in userspace