Lines Matching +full:support +full:- +full:nesting
1 .. SPDX-License-Identifier: GPL-2.0+
19 At minimum iommufd provides universal support of managing I/O address spaces and
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_HWPT_PAGING, representing an actual hardware I/O page table
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
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
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|
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
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.
223 and an hwpt_id (to associate the vIOMMU to a nesting parent HWPT_PAGING). The
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.
243 most one IOAS object (no support of PASID yet).
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
335 change but better matches the IOMMUFD API semantics and easier to support new
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