Lines Matching +full:user +full:- +full:visible
1 .. SPDX-License-Identifier: GPL-2.0+
13 IOMMUFD is the user API to control the IOMMU subsystem as it relates to managing
20 I/O page tables for all IOMMUs, with room in the design to add non-generic
30 User Visible Objects
31 --------------------
35 - IOMMUFD_OBJ_IOAS, representing an I/O address space (IOAS), allowing map/unmap
36 of user space memory into ranges of I/O Virtual Address (IOVA).
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
56 (i.e. a single struct iommu_domain) managed by user space (e.g. guest OS).
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_FAULT, representing a software queue for an HWPT reporting IO page
68 provides user space an FD to poll the page fault events and also to respond
70 could be then used to allocate a fault-enabled HWPT via the IOMMU_HWPT_ALLOC
73 - IOMMUFD_OBJ_VIOMMU, representing a slice of the physical IOMMU instance,
74 passed to or shared with a VM. It may be some HW-accelerated virtualization
77 * Security namespace for guest owned ID, e.g. guest-controlled cache tags
78 * Non-device-affiliated event reporting, e.g. invalidation queue errors
86 to support some HW-accelerated virtualization features. So, a vIOMMU object
102 passed-through devices would be connected to their own virtualized IOMMUs
106 - IOMMUFD_OBJ_VDEVICE, representing a virtual device for an IOMMUFD_OBJ_DEVICE
111 e.g. vSID of ARM SMMUv3, vDeviceID of AMD IOMMU, and vRID of Intel VT-d to a
119 - IOMMUFD_OBJ_VEVENTQ, representing a software queue for a vIOMMU to report its
120 events such as translation faults occurred to a nested stage-1 (excluding I/O
121 page faults that should go through IOMMUFD_OBJ_FAULT) and HW-specific events.
122 This queue object provides user space an FD to poll/read the vIOMMU events. A
127 - IOMMUFD_OBJ_HW_QUEUE, representing a hardware accelerated queue, as a subset
129 the virtual queue memory owned by a guest OS. This HW-acceleration feature can
132 user space an mmap interface for VMM to mmap a physical MMIO region from the
138 All user-visible objects are destroyed via the IOMMU_DESTROY uAPI.
140 The diagrams below show relationships between user-visible objects and kernel
150 | | IOAS |<---| HWPT_PAGING |<---------------------| DEVICE | |
157 |------------>|iommu_domain|<-----------------------|device|
166 | | IOAS |<---| HWPT_PAGING |<---| HWPT_NESTED |<--| DEVICE | |
173 |------------>|iommu_domain|<----|iommu_domain|<----|device|
182 | |----------------| vIOMMU |<---| vDEVICE |<----| |
188 | | | IOAS |<---|(HWPT_PAGING)|<---| HWPT_NESTED |<--| DEVICE | |
195 |iommu_device| |------>|iommu_domain|<----|iommu_domain|<----|device|
237 and iommu_domains. Once this completes the device could do DMA via a 2-stage
252 to allocate its own vIOMMU data structure embedding the core-level structure
253 iommufd_viommu and some driver-specific data. If necessary, the driver can
272 --------------------
274 User visible objects are backed by following datastructures:
276 - iommufd_ioas for IOMMUFD_OBJ_IOAS.
277 - iommufd_device for IOMMUFD_OBJ_DEVICE.
278 - iommufd_hwpt_paging for IOMMUFD_OBJ_HWPT_PAGING.
279 - iommufd_hwpt_nested for IOMMUFD_OBJ_HWPT_NESTED.
280 - iommufd_fault for IOMMUFD_OBJ_FAULT.
281 - iommufd_viommu for IOMMUFD_OBJ_VIOMMU.
282 - iommufd_vdevice for IOMMUFD_OBJ_VDEVICE.
283 - iommufd_veventq for IOMMUFD_OBJ_VEVENTQ.
284 - iommufd_hw_queue for IOMMUFD_OBJ_HW_QUEUE.
288 - Automatic domain - refers to an iommu domain created automatically when
292 - Manual domain - refers to an iommu domain designated by the user as the
297 - In-kernel user - refers to something like a VFIO mdev that is using the
306 - struct io_pagetable holding the IOVA map
307 - struct iopt_area's representing populated portions of IOVA
308 - struct iopt_pages representing the storage of PFNs
309 - struct iommu_domain representing the IO page table in the IOMMU
310 - struct iopt_pages_access representing in-kernel users of PFNs
311 - struct xarray pinned_pfns holding a list of pages pinned by in-kernel users
319 on what domains are present and what kinds of in-kernel "software access" users
325 Multiple io_pagetable-s, through their iopt_area-s, can share a single
326 iopt_pages which avoids multi-pinning and double accounting of page
332 IOMMUFD User API
335 .. kernel-doc:: include/uapi/linux/iommufd.h
340 The IOMMUFD kAPI is device-centric with group-related tricks managed behind the
342 device-centric uAPI for connecting its device to an iommufd, instead of
345 .. kernel-doc:: drivers/iommu/iommufd/device.c
348 .. kernel-doc:: drivers/iommu/iommufd/main.c
352 ----------------
362 The second approach directly extends VFIO to support a new set of device-centric
363 user API based on aforementioned IOMMUFD kernel API. It requires userspace
367 Currently both approaches are still work-in-progress.
375 Currently IOMMUFD supports only kernel-managed I/O page table, similar to VFIO
378 - Binding iommu_domain's to PASID/SSID
379 - Userspace page tables, for ARM, x86 and S390
380 - Kernel bypass'd invalidation of user page tables
381 - Re-use of the KVM page table in the IOMMU
382 - Dirty page tracking in the IOMMU
383 - Runtime Increase/Decrease of IOPTE size
384 - PRI support with faults resolved in userspace