1.. SPDX-License-Identifier: GPL-2.0
  2.. iommu:
  3
  4=====================================
  5IOMMU Userspace API
  6=====================================
  7
  8IOMMU UAPI is used for virtualization cases where communications are
  9needed between physical and virtual IOMMU drivers. For baremetal
 10usage, the IOMMU is a system device which does not need to communicate
 11with userspace directly.
 12
 13The primary use cases are guest Shared Virtual Address (SVA) and
 14guest IO virtual address (IOVA), wherein the vIOMMU implementation
 15relies on the physical IOMMU and for this reason requires interactions
 16with the host driver.
 17
 18.. contents:: :local:
 19
 20Functionalities
 21===============
 22Communications of user and kernel involve both directions. The
 23supported user-kernel APIs are as follows:
 24
 251. Bind/Unbind guest PASID (e.g. Intel VT-d)
 262. Bind/Unbind guest PASID table (e.g. ARM SMMU)
 273. Invalidate IOMMU caches upon guest requests
 284. Report errors to the guest and serve page requests
 29
 30Requirements
 31============
 32The IOMMU UAPIs are generic and extensible to meet the following
 33requirements:
 34
 351. Emulated and para-virtualised vIOMMUs
 362. Multiple vendors (Intel VT-d, ARM SMMU, etc.)
 373. Extensions to the UAPI shall not break existing userspace
 38
 39Interfaces
 40==========
 41Although the data structures defined in IOMMU UAPI are self-contained,
 42there are no user API functions introduced. Instead, IOMMU UAPI is
 43designed to work with existing user driver frameworks such as VFIO.
 44
 45Extension Rules & Precautions
 46-----------------------------
 47When IOMMU UAPI gets extended, the data structures can *only* be
 48modified in two ways:
 49
 501. Adding new fields by re-purposing the padding[] field. No size change.
 512. Adding new union members at the end. May increase the structure sizes.
 52
 53No new fields can be added *after* the variable sized union in that it
 54will break backward compatibility when offset moves. A new flag must
 55be introduced whenever a change affects the structure using either
 56method. The IOMMU driver processes the data based on flags which
 57ensures backward compatibility.
 58
 59Version field is only reserved for the unlikely event of UAPI upgrade
 60at its entirety.
 61
 62It's *always* the caller's responsibility to indicate the size of the
 63structure passed by setting argsz appropriately.
 64Though at the same time, argsz is user provided data which is not
 65trusted. The argsz field allows the user app to indicate how much data
 66it is providing; it's still the kernel's responsibility to validate
 67whether it's correct and sufficient for the requested operation.
 68
 69Compatibility Checking
 70----------------------
 71When IOMMU UAPI extension results in some structure size increase,
 72IOMMU UAPI code shall handle the following cases:
 73
 741. User and kernel has exact size match
 752. An older user with older kernel header (smaller UAPI size) running on a
 76   newer kernel (larger UAPI size)
 773. A newer user with newer kernel header (larger UAPI size) running
 78   on an older kernel.
 794. A malicious/misbehaving user passing illegal/invalid size but within
 80   range. The data may contain garbage.
 81
 82Feature Checking
 83----------------
 84While launching a guest with vIOMMU, it is strongly advised to check
 85the compatibility upfront, as some subsequent errors happening during
 86vIOMMU operation, such as cache invalidation failures cannot be nicely
 87escalated to the guest due to IOMMU specifications. This can lead to
 88catastrophic failures for the users.
 89
 90User applications such as QEMU are expected to import kernel UAPI
 91headers. Backward compatibility is supported per feature flags.
 92For example, an older QEMU (with older kernel header) can run on newer
 93kernel. Newer QEMU (with new kernel header) may refuse to initialize
 94on an older kernel if new feature flags are not supported by older
 95kernel. Simply recompiling existing code with newer kernel header should
 96not be an issue in that only existing flags are used.
 97
 98IOMMU vendor driver should report the below features to IOMMU UAPI
 99consumers (e.g. via VFIO).
100
1011. IOMMU_NESTING_FEAT_SYSWIDE_PASID
1022. IOMMU_NESTING_FEAT_BIND_PGTBL
1033. IOMMU_NESTING_FEAT_BIND_PASID_TABLE
1044. IOMMU_NESTING_FEAT_CACHE_INVLD
1055. IOMMU_NESTING_FEAT_PAGE_REQUEST
106
107Take VFIO as example, upon request from VFIO userspace (e.g. QEMU),
108VFIO kernel code shall query IOMMU vendor driver for the support of
109the above features. Query result can then be reported back to the
110userspace caller. Details can be found in
111Documentation/driver-api/vfio.rst.
112
113
114Data Passing Example with VFIO
115------------------------------
116As the ubiquitous userspace driver framework, VFIO is already IOMMU
117aware and shares many key concepts such as device model, group, and
118protection domain. Other user driver frameworks can also be extended
119to support IOMMU UAPI but it is outside the scope of this document.
120
121In this tight-knit VFIO-IOMMU interface, the ultimate consumer of the
122IOMMU UAPI data is the host IOMMU driver. VFIO facilitates user-kernel
123transport, capability checking, security, and life cycle management of
124process address space ID (PASID).
125
126VFIO layer conveys the data structures down to the IOMMU driver. It
127follows the pattern below::
128
129   struct {
130	__u32 argsz;
131	__u32 flags;
132	__u8  data[];
133   };
134
135Here data[] contains the IOMMU UAPI data structures. VFIO has the
136freedom to bundle the data as well as parse data size based on its own flags.
137
138In order to determine the size and feature set of the user data, argsz
139and flags (or the equivalent) are also embedded in the IOMMU UAPI data
140structures.
141
142A "__u32 argsz" field is *always* at the beginning of each structure.
143
144For example:
145::
146
147   struct iommu_cache_invalidate_info {
148	__u32	argsz;
149	#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1
150	__u32	version;
151	/* IOMMU paging structure cache */
152	#define IOMMU_CACHE_INV_TYPE_IOTLB	(1 << 0) /* IOMMU IOTLB */
153	#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB	(1 << 1) /* Device IOTLB */
154	#define IOMMU_CACHE_INV_TYPE_PASID	(1 << 2) /* PASID cache */
155	#define IOMMU_CACHE_INV_TYPE_NR		(3)
156	__u8	cache;
157	__u8	granularity;
158	__u8	padding[6];
159	union {
160		struct iommu_inv_pasid_info pasid_info;
161		struct iommu_inv_addr_info addr_info;
162	} granu;
163   };
164
165VFIO is responsible for checking its own argsz and flags. It then
166invokes appropriate IOMMU UAPI functions. The user pointers are passed
167to the IOMMU layer for further processing. The responsibilities are
168divided as follows:
169
170- Generic IOMMU layer checks argsz range based on UAPI data in the
171  current kernel version.
172
173- Generic IOMMU layer checks content of the UAPI data for non-zero
174  reserved bits in flags, padding fields, and unsupported version.
175  This is to ensure not breaking userspace in the future when these
176  fields or flags are used.
177
178- Vendor IOMMU driver checks argsz based on vendor flags. UAPI data
179  is consumed based on flags. Vendor driver has access to
180  unadulterated argsz value in case of vendor specific future
181  extensions. Currently, it does not perform the copy_from_user()
182  itself. A __user pointer can be provided in some future scenarios
183  where there's vendor data outside of the structure definition.
184
185IOMMU code treats UAPI data in two categories:
186
187- structure contains vendor data
188  (Example: iommu_uapi_cache_invalidate())
189
190- structure contains only generic data
191  (Example: iommu_uapi_sva_bind_gpasid())
192
193
194
195Sharing UAPI with in-kernel users
196---------------------------------
197For UAPIs that are shared with in-kernel users, a wrapper function is
198provided to distinguish the callers. For example,
199
200Userspace caller ::
201
202  int iommu_uapi_sva_unbind_gpasid(struct iommu_domain *domain,
203                                   struct device *dev,
204                                   void __user *udata)
205
206In-kernel caller ::
207
208  int iommu_sva_unbind_gpasid(struct iommu_domain *domain,
209                              struct device *dev, ioasid_t ioasid);