| 1 | Buffer Sharing and Synchronization (dma-buf) |
| 2 | ============================================ |
| 3 | |
| 4 | The dma-buf subsystem provides the framework for sharing buffers for |
| 5 | hardware (DMA) access across multiple device drivers and subsystems, and |
| 6 | for synchronizing asynchronous hardware access. |
| 7 | |
| 8 | As an example, it is used extensively by the DRM subsystem to exchange |
| 9 | buffers between processes, contexts, library APIs within the same |
| 10 | process, and also to exchange buffers with other subsystems such as |
| 11 | V4L2. |
| 12 | |
| 13 | This document describes the way in which kernel subsystems can use and |
| 14 | interact with the three main primitives offered by dma-buf: |
| 15 | |
| 16 | - dma-buf, representing a sg_table and exposed to userspace as a file |
| 17 | descriptor to allow passing between processes, subsystems, devices, |
| 18 | etc; |
| 19 | - dma-fence, providing a mechanism to signal when an asynchronous |
| 20 | hardware operation has completed; and |
| 21 | - dma-resv, which manages a set of dma-fences for a particular dma-buf |
| 22 | allowing implicit (kernel-ordered) synchronization of work to |
| 23 | preserve the illusion of coherent access |
| 24 | |
| 25 | |
| 26 | Userspace API principles and use |
| 27 | -------------------------------- |
| 28 | |
| 29 | For more details on how to design your subsystem's API for dma-buf use, please |
| 30 | see Documentation/userspace-api/dma-buf-alloc-exchange.rst. |
| 31 | |
| 32 | |
| 33 | Shared DMA Buffers |
| 34 | ------------------ |
| 35 | |
| 36 | This document serves as a guide to device-driver writers on what is the dma-buf |
| 37 | buffer sharing API, how to use it for exporting and using shared buffers. |
| 38 | |
| 39 | Any device driver which wishes to be a part of DMA buffer sharing, can do so as |
| 40 | either the 'exporter' of buffers, or the 'user' or 'importer' of buffers. |
| 41 | |
| 42 | Say a driver A wants to use buffers created by driver B, then we call B as the |
| 43 | exporter, and A as buffer-user/importer. |
| 44 | |
| 45 | The exporter |
| 46 | |
| 47 | - implements and manages operations in :c:type:`struct dma_buf_ops |
| 48 | <dma_buf_ops>` for the buffer, |
| 49 | - allows other users to share the buffer by using dma_buf sharing APIs, |
| 50 | - manages the details of buffer allocation, wrapped in a :c:type:`struct |
| 51 | dma_buf <dma_buf>`, |
| 52 | - decides about the actual backing storage where this allocation happens, |
| 53 | - and takes care of any migration of scatterlist - for all (shared) users of |
| 54 | this buffer. |
| 55 | |
| 56 | The buffer-user |
| 57 | |
| 58 | - is one of (many) sharing users of the buffer. |
| 59 | - doesn't need to worry about how the buffer is allocated, or where. |
| 60 | - and needs a mechanism to get access to the scatterlist that makes up this |
| 61 | buffer in memory, mapped into its own address space, so it can access the |
| 62 | same area of memory. This interface is provided by :c:type:`struct |
| 63 | dma_buf_attachment <dma_buf_attachment>`. |
| 64 | |
| 65 | Any exporters or users of the dma-buf buffer sharing framework must have a |
| 66 | 'select DMA_SHARED_BUFFER' in their respective Kconfigs. |
| 67 | |
| 68 | Userspace Interface Notes |
| 69 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 70 | |
| 71 | Mostly a DMA buffer file descriptor is simply an opaque object for userspace, |
| 72 | and hence the generic interface exposed is very minimal. There's a few things to |
| 73 | consider though: |
| 74 | |
| 75 | - Since kernel 3.12 the dma-buf FD supports the llseek system call, but only |
| 76 | with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow |
| 77 | the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other |
| 78 | llseek operation will report -EINVAL. |
| 79 | |
| 80 | If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all |
| 81 | cases. Userspace can use this to detect support for discovering the dma-buf |
| 82 | size using llseek. |
| 83 | |
| 84 | - In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set |
| 85 | on the file descriptor. This is not just a resource leak, but a |
| 86 | potential security hole. It could give the newly exec'd application |
| 87 | access to buffers, via the leaked fd, to which it should otherwise |
| 88 | not be permitted access. |
| 89 | |
| 90 | The problem with doing this via a separate fcntl() call, versus doing it |
| 91 | atomically when the fd is created, is that this is inherently racy in a |
| 92 | multi-threaded app[3]. The issue is made worse when it is library code |
| 93 | opening/creating the file descriptor, as the application may not even be |
| 94 | aware of the fd's. |
| 95 | |
| 96 | To avoid this problem, userspace must have a way to request O_CLOEXEC |
| 97 | flag be set when the dma-buf fd is created. So any API provided by |
| 98 | the exporting driver to create a dmabuf fd must provide a way to let |
| 99 | userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). |
| 100 | |
| 101 | - Memory mapping the contents of the DMA buffer is also supported. See the |
| 102 | discussion below on `CPU Access to DMA Buffer Objects`_ for the full details. |
| 103 | |
| 104 | - The DMA buffer FD is also pollable, see `Implicit Fence Poll Support`_ below for |
| 105 | details. |
| 106 | |
| 107 | - The DMA buffer FD also supports a few dma-buf-specific ioctls, see |
| 108 | `DMA Buffer ioctls`_ below for details. |
| 109 | |
| 110 | Basic Operation and Device DMA Access |
| 111 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 112 | |
| 113 | .. kernel-doc:: drivers/dma-buf/dma-buf.c |
| 114 | :doc: dma buf device access |
| 115 | |
| 116 | CPU Access to DMA Buffer Objects |
| 117 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 118 | |
| 119 | .. kernel-doc:: drivers/dma-buf/dma-buf.c |
| 120 | :doc: cpu access |
| 121 | |
| 122 | Implicit Fence Poll Support |
| 123 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 124 | |
| 125 | .. kernel-doc:: drivers/dma-buf/dma-buf.c |
| 126 | :doc: implicit fence polling |
| 127 | |
| 128 | DMA-BUF statistics |
| 129 | ~~~~~~~~~~~~~~~~~~ |
| 130 | .. kernel-doc:: drivers/dma-buf/dma-buf-sysfs-stats.c |
| 131 | :doc: overview |
| 132 | |
| 133 | DMA Buffer ioctls |
| 134 | ~~~~~~~~~~~~~~~~~ |
| 135 | |
| 136 | .. kernel-doc:: include/uapi/linux/dma-buf.h |
| 137 | |
| 138 | DMA-BUF locking convention |
| 139 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 140 | |
| 141 | .. kernel-doc:: drivers/dma-buf/dma-buf.c |
| 142 | :doc: locking convention |
| 143 | |
| 144 | Kernel Functions and Structures Reference |
| 145 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 146 | |
| 147 | .. kernel-doc:: drivers/dma-buf/dma-buf.c |
| 148 | :export: |
| 149 | |
| 150 | .. kernel-doc:: include/linux/dma-buf.h |
| 151 | :internal: |
| 152 | |
| 153 | Reservation Objects |
| 154 | ------------------- |
| 155 | |
| 156 | .. kernel-doc:: drivers/dma-buf/dma-resv.c |
| 157 | :doc: Reservation Object Overview |
| 158 | |
| 159 | .. kernel-doc:: drivers/dma-buf/dma-resv.c |
| 160 | :export: |
| 161 | |
| 162 | .. kernel-doc:: include/linux/dma-resv.h |
| 163 | :internal: |
| 164 | |
| 165 | DMA Fences |
| 166 | ---------- |
| 167 | |
| 168 | .. kernel-doc:: drivers/dma-buf/dma-fence.c |
| 169 | :doc: DMA fences overview |
| 170 | |
| 171 | DMA Fence Cross-Driver Contract |
| 172 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 173 | |
| 174 | .. kernel-doc:: drivers/dma-buf/dma-fence.c |
| 175 | :doc: fence cross-driver contract |
| 176 | |
| 177 | DMA Fence Signalling Annotations |
| 178 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 179 | |
| 180 | .. kernel-doc:: drivers/dma-buf/dma-fence.c |
| 181 | :doc: fence signalling annotation |
| 182 | |
| 183 | DMA Fence Deadline Hints |
| 184 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
| 185 | |
| 186 | .. kernel-doc:: drivers/dma-buf/dma-fence.c |
| 187 | :doc: deadline hints |
| 188 | |
| 189 | DMA Fences Functions Reference |
| 190 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 191 | |
| 192 | .. kernel-doc:: drivers/dma-buf/dma-fence.c |
| 193 | :export: |
| 194 | |
| 195 | .. kernel-doc:: include/linux/dma-fence.h |
| 196 | :internal: |
| 197 | |
| 198 | DMA Fence Array |
| 199 | ~~~~~~~~~~~~~~~ |
| 200 | |
| 201 | .. kernel-doc:: drivers/dma-buf/dma-fence-array.c |
| 202 | :export: |
| 203 | |
| 204 | .. kernel-doc:: include/linux/dma-fence-array.h |
| 205 | :internal: |
| 206 | |
| 207 | DMA Fence Chain |
| 208 | ~~~~~~~~~~~~~~~ |
| 209 | |
| 210 | .. kernel-doc:: drivers/dma-buf/dma-fence-chain.c |
| 211 | :export: |
| 212 | |
| 213 | .. kernel-doc:: include/linux/dma-fence-chain.h |
| 214 | :internal: |
| 215 | |
| 216 | DMA Fence unwrap |
| 217 | ~~~~~~~~~~~~~~~~ |
| 218 | |
| 219 | .. kernel-doc:: include/linux/dma-fence-unwrap.h |
| 220 | :internal: |
| 221 | |
| 222 | DMA Fence Sync File |
| 223 | ~~~~~~~~~~~~~~~~~~~ |
| 224 | |
| 225 | .. kernel-doc:: drivers/dma-buf/sync_file.c |
| 226 | :export: |
| 227 | |
| 228 | .. kernel-doc:: include/linux/sync_file.h |
| 229 | :internal: |
| 230 | |
| 231 | DMA Fence Sync File uABI |
| 232 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
| 233 | |
| 234 | .. kernel-doc:: include/uapi/linux/sync_file.h |
| 235 | :internal: |
| 236 | |
| 237 | Indefinite DMA Fences |
| 238 | ~~~~~~~~~~~~~~~~~~~~~ |
| 239 | |
| 240 | At various times struct dma_fence with an indefinite time until dma_fence_wait() |
| 241 | finishes have been proposed. Examples include: |
| 242 | |
| 243 | * Future fences, used in HWC1 to signal when a buffer isn't used by the display |
| 244 | any longer, and created with the screen update that makes the buffer visible. |
| 245 | The time this fence completes is entirely under userspace's control. |
| 246 | |
| 247 | * Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet |
| 248 | been set. Used to asynchronously delay command submission. |
| 249 | |
| 250 | * Userspace fences or gpu futexes, fine-grained locking within a command buffer |
| 251 | that userspace uses for synchronization across engines or with the CPU, which |
| 252 | are then imported as a DMA fence for integration into existing winsys |
| 253 | protocols. |
| 254 | |
| 255 | * Long-running compute command buffers, while still using traditional end of |
| 256 | batch DMA fences for memory management instead of context preemption DMA |
| 257 | fences which get reattached when the compute job is rescheduled. |
| 258 | |
| 259 | Common to all these schemes is that userspace controls the dependencies of these |
| 260 | fences and controls when they fire. Mixing indefinite fences with normal |
| 261 | in-kernel DMA fences does not work, even when a fallback timeout is included to |
| 262 | protect against malicious userspace: |
| 263 | |
| 264 | * Only the kernel knows about all DMA fence dependencies, userspace is not aware |
| 265 | of dependencies injected due to memory management or scheduler decisions. |
| 266 | |
| 267 | * Only userspace knows about all dependencies in indefinite fences and when |
| 268 | exactly they will complete, the kernel has no visibility. |
| 269 | |
| 270 | Furthermore the kernel has to be able to hold up userspace command submission |
| 271 | for memory management needs, which means we must support indefinite fences being |
| 272 | dependent upon DMA fences. If the kernel also support indefinite fences in the |
| 273 | kernel like a DMA fence, like any of the above proposal would, there is the |
| 274 | potential for deadlocks. |
| 275 | |
| 276 | .. kernel-render:: DOT |
| 277 | :alt: Indefinite Fencing Dependency Cycle |
| 278 | :caption: Indefinite Fencing Dependency Cycle |
| 279 | |
| 280 | digraph "Fencing Cycle" { |
| 281 | node [shape=box bgcolor=grey style=filled] |
| 282 | kernel [label="Kernel DMA Fences"] |
| 283 | userspace [label="userspace controlled fences"] |
| 284 | kernel -> userspace [label="memory management"] |
| 285 | userspace -> kernel [label="Future fence, fence proxy, ..."] |
| 286 | |
| 287 | { rank=same; kernel userspace } |
| 288 | } |
| 289 | |
| 290 | This means that the kernel might accidentally create deadlocks |
| 291 | through memory management dependencies which userspace is unaware of, which |
| 292 | randomly hangs workloads until the timeout kicks in. Workloads, which from |
| 293 | userspace's perspective, do not contain a deadlock. In such a mixed fencing |
| 294 | architecture there is no single entity with knowledge of all dependencies. |
| 295 | Therefore preventing such deadlocks from within the kernel is not possible. |
| 296 | |
| 297 | The only solution to avoid dependencies loops is by not allowing indefinite |
| 298 | fences in the kernel. This means: |
| 299 | |
| 300 | * No future fences, proxy fences or userspace fences imported as DMA fences, |
| 301 | with or without a timeout. |
| 302 | |
| 303 | * No DMA fences that signal end of batchbuffer for command submission where |
| 304 | userspace is allowed to use userspace fencing or long running compute |
| 305 | workloads. This also means no implicit fencing for shared buffers in these |
| 306 | cases. |
| 307 | |
| 308 | Recoverable Hardware Page Faults Implications |
| 309 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 310 | |
| 311 | Modern hardware supports recoverable page faults, which has a lot of |
| 312 | implications for DMA fences. |
| 313 | |
| 314 | First, a pending page fault obviously holds up the work that's running on the |
| 315 | accelerator and a memory allocation is usually required to resolve the fault. |
| 316 | But memory allocations are not allowed to gate completion of DMA fences, which |
| 317 | means any workload using recoverable page faults cannot use DMA fences for |
| 318 | synchronization. Synchronization fences controlled by userspace must be used |
| 319 | instead. |
| 320 | |
| 321 | On GPUs this poses a problem, because current desktop compositor protocols on |
| 322 | Linux rely on DMA fences, which means without an entirely new userspace stack |
| 323 | built on top of userspace fences, they cannot benefit from recoverable page |
| 324 | faults. Specifically this means implicit synchronization will not be possible. |
| 325 | The exception is when page faults are only used as migration hints and never to |
| 326 | on-demand fill a memory request. For now this means recoverable page |
| 327 | faults on GPUs are limited to pure compute workloads. |
| 328 | |
| 329 | Furthermore GPUs usually have shared resources between the 3D rendering and |
| 330 | compute side, like compute units or command submission engines. If both a 3D |
| 331 | job with a DMA fence and a compute workload using recoverable page faults are |
| 332 | pending they could deadlock: |
| 333 | |
| 334 | - The 3D workload might need to wait for the compute job to finish and release |
| 335 | hardware resources first. |
| 336 | |
| 337 | - The compute workload might be stuck in a page fault, because the memory |
| 338 | allocation is waiting for the DMA fence of the 3D workload to complete. |
| 339 | |
| 340 | There are a few options to prevent this problem, one of which drivers need to |
| 341 | ensure: |
| 342 | |
| 343 | - Compute workloads can always be preempted, even when a page fault is pending |
| 344 | and not yet repaired. Not all hardware supports this. |
| 345 | |
| 346 | - DMA fence workloads and workloads which need page fault handling have |
| 347 | independent hardware resources to guarantee forward progress. This could be |
| 348 | achieved through e.g. through dedicated engines and minimal compute unit |
| 349 | reservations for DMA fence workloads. |
| 350 | |
| 351 | - The reservation approach could be further refined by only reserving the |
| 352 | hardware resources for DMA fence workloads when they are in-flight. This must |
| 353 | cover the time from when the DMA fence is visible to other threads up to |
| 354 | moment when fence is completed through dma_fence_signal(). |
| 355 | |
| 356 | - As a last resort, if the hardware provides no useful reservation mechanics, |
| 357 | all workloads must be flushed from the GPU when switching between jobs |
| 358 | requiring DMA fences or jobs requiring page fault handling: This means all DMA |
| 359 | fences must complete before a compute job with page fault handling can be |
| 360 | inserted into the scheduler queue. And vice versa, before a DMA fence can be |
| 361 | made visible anywhere in the system, all compute workloads must be preempted |
| 362 | to guarantee all pending GPU page faults are flushed. |
| 363 | |
| 364 | - Only a fairly theoretical option would be to untangle these dependencies when |
| 365 | allocating memory to repair hardware page faults, either through separate |
| 366 | memory blocks or runtime tracking of the full dependency graph of all DMA |
| 367 | fences. This results very wide impact on the kernel, since resolving the page |
| 368 | on the CPU side can itself involve a page fault. It is much more feasible and |
| 369 | robust to limit the impact of handling hardware page faults to the specific |
| 370 | driver. |
| 371 | |
| 372 | Note that workloads that run on independent hardware like copy engines or other |
| 373 | GPUs do not have any impact. This allows us to keep using DMA fences internally |
| 374 | in the kernel even for resolving hardware page faults, e.g. by using copy |
| 375 | engines to clear or copy memory needed to resolve the page fault. |
| 376 | |
| 377 | In some ways this page fault problem is a special case of the `Infinite DMA |
| 378 | Fences` discussions: Infinite fences from compute workloads are allowed to |
| 379 | depend on DMA fences, but not the other way around. And not even the page fault |
| 380 | problem is new, because some other CPU thread in userspace might |
| 381 | hit a page fault which holds up a userspace fence - supporting page faults on |
| 382 | GPUs doesn't anything fundamentally new. |