| 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 Buffer ioctls
|
| 129 | ~~~~~~~~~~~~~~~~~
|
| 130 |
|
| 131 | .. kernel-doc:: include/uapi/linux/dma-buf.h
|
| 132 |
|
| 133 | DMA-BUF locking convention
|
| 134 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 135 |
|
| 136 | .. kernel-doc:: drivers/dma-buf/dma-buf.c
|
| 137 | :doc: locking convention
|
| 138 |
|
| 139 | Kernel Functions and Structures Reference
|
| 140 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 141 |
|
| 142 | .. kernel-doc:: drivers/dma-buf/dma-buf.c
|
| 143 | :export:
|
| 144 |
|
| 145 | .. kernel-doc:: include/linux/dma-buf.h
|
| 146 | :internal:
|
| 147 |
|
| 148 | Reservation Objects
|
| 149 | -------------------
|
| 150 |
|
| 151 | .. kernel-doc:: drivers/dma-buf/dma-resv.c
|
| 152 | :doc: Reservation Object Overview
|
| 153 |
|
| 154 | .. kernel-doc:: drivers/dma-buf/dma-resv.c
|
| 155 | :export:
|
| 156 |
|
| 157 | .. kernel-doc:: include/linux/dma-resv.h
|
| 158 | :internal:
|
| 159 |
|
| 160 | DMA Fences
|
| 161 | ----------
|
| 162 |
|
| 163 | .. kernel-doc:: drivers/dma-buf/dma-fence.c
|
| 164 | :doc: DMA fences overview
|
| 165 |
|
| 166 | DMA Fence Cross-Driver Contract
|
| 167 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 168 |
|
| 169 | .. kernel-doc:: drivers/dma-buf/dma-fence.c
|
| 170 | :doc: fence cross-driver contract
|
| 171 |
|
| 172 | DMA Fence Signalling Annotations
|
| 173 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 174 |
|
| 175 | .. kernel-doc:: drivers/dma-buf/dma-fence.c
|
| 176 | :doc: fence signalling annotation
|
| 177 |
|
| 178 | DMA Fence Deadline Hints
|
| 179 | ~~~~~~~~~~~~~~~~~~~~~~~~
|
| 180 |
|
| 181 | .. kernel-doc:: drivers/dma-buf/dma-fence.c
|
| 182 | :doc: deadline hints
|
| 183 |
|
| 184 | DMA Fences Functions Reference
|
| 185 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 186 |
|
| 187 | .. kernel-doc:: drivers/dma-buf/dma-fence.c
|
| 188 | :export:
|
| 189 |
|
| 190 | .. kernel-doc:: include/linux/dma-fence.h
|
| 191 | :internal:
|
| 192 |
|
| 193 | DMA Fence Array
|
| 194 | ~~~~~~~~~~~~~~~
|
| 195 |
|
| 196 | .. kernel-doc:: drivers/dma-buf/dma-fence-array.c
|
| 197 | :export:
|
| 198 |
|
| 199 | .. kernel-doc:: include/linux/dma-fence-array.h
|
| 200 | :internal:
|
| 201 |
|
| 202 | DMA Fence Chain
|
| 203 | ~~~~~~~~~~~~~~~
|
| 204 |
|
| 205 | .. kernel-doc:: drivers/dma-buf/dma-fence-chain.c
|
| 206 | :export:
|
| 207 |
|
| 208 | .. kernel-doc:: include/linux/dma-fence-chain.h
|
| 209 | :internal:
|
| 210 |
|
| 211 | DMA Fence unwrap
|
| 212 | ~~~~~~~~~~~~~~~~
|
| 213 |
|
| 214 | .. kernel-doc:: include/linux/dma-fence-unwrap.h
|
| 215 | :internal:
|
| 216 |
|
| 217 | DMA Fence Sync File
|
| 218 | ~~~~~~~~~~~~~~~~~~~
|
| 219 |
|
| 220 | .. kernel-doc:: drivers/dma-buf/sync_file.c
|
| 221 | :export:
|
| 222 |
|
| 223 | .. kernel-doc:: include/linux/sync_file.h
|
| 224 | :internal:
|
| 225 |
|
| 226 | DMA Fence Sync File uABI
|
| 227 | ~~~~~~~~~~~~~~~~~~~~~~~~
|
| 228 |
|
| 229 | .. kernel-doc:: include/uapi/linux/sync_file.h
|
| 230 | :internal:
|
| 231 |
|
| 232 | Indefinite DMA Fences
|
| 233 | ~~~~~~~~~~~~~~~~~~~~~
|
| 234 |
|
| 235 | At various times struct dma_fence with an indefinite time until dma_fence_wait()
|
| 236 | finishes have been proposed. Examples include:
|
| 237 |
|
| 238 | * Future fences, used in HWC1 to signal when a buffer isn't used by the display
|
| 239 | any longer, and created with the screen update that makes the buffer visible.
|
| 240 | The time this fence completes is entirely under userspace's control.
|
| 241 |
|
| 242 | * Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet
|
| 243 | been set. Used to asynchronously delay command submission.
|
| 244 |
|
| 245 | * Userspace fences or gpu futexes, fine-grained locking within a command buffer
|
| 246 | that userspace uses for synchronization across engines or with the CPU, which
|
| 247 | are then imported as a DMA fence for integration into existing winsys
|
| 248 | protocols.
|
| 249 |
|
| 250 | * Long-running compute command buffers, while still using traditional end of
|
| 251 | batch DMA fences for memory management instead of context preemption DMA
|
| 252 | fences which get reattached when the compute job is rescheduled.
|
| 253 |
|
| 254 | Common to all these schemes is that userspace controls the dependencies of these
|
| 255 | fences and controls when they fire. Mixing indefinite fences with normal
|
| 256 | in-kernel DMA fences does not work, even when a fallback timeout is included to
|
| 257 | protect against malicious userspace:
|
| 258 |
|
| 259 | * Only the kernel knows about all DMA fence dependencies, userspace is not aware
|
| 260 | of dependencies injected due to memory management or scheduler decisions.
|
| 261 |
|
| 262 | * Only userspace knows about all dependencies in indefinite fences and when
|
| 263 | exactly they will complete, the kernel has no visibility.
|
| 264 |
|
| 265 | Furthermore the kernel has to be able to hold up userspace command submission
|
| 266 | for memory management needs, which means we must support indefinite fences being
|
| 267 | dependent upon DMA fences. If the kernel also support indefinite fences in the
|
| 268 | kernel like a DMA fence, like any of the above proposal would, there is the
|
| 269 | potential for deadlocks.
|
| 270 |
|
| 271 | .. kernel-render:: DOT
|
| 272 | :alt: Indefinite Fencing Dependency Cycle
|
| 273 | :caption: Indefinite Fencing Dependency Cycle
|
| 274 |
|
| 275 | digraph "Fencing Cycle" {
|
| 276 | node [shape=box bgcolor=grey style=filled]
|
| 277 | kernel [label="Kernel DMA Fences"]
|
| 278 | userspace [label="userspace controlled fences"]
|
| 279 | kernel -> userspace [label="memory management"]
|
| 280 | userspace -> kernel [label="Future fence, fence proxy, ..."]
|
| 281 |
|
| 282 | { rank=same; kernel userspace }
|
| 283 | }
|
| 284 |
|
| 285 | This means that the kernel might accidentally create deadlocks
|
| 286 | through memory management dependencies which userspace is unaware of, which
|
| 287 | randomly hangs workloads until the timeout kicks in. Workloads, which from
|
| 288 | userspace's perspective, do not contain a deadlock. In such a mixed fencing
|
| 289 | architecture there is no single entity with knowledge of all dependencies.
|
| 290 | Therefore preventing such deadlocks from within the kernel is not possible.
|
| 291 |
|
| 292 | The only solution to avoid dependencies loops is by not allowing indefinite
|
| 293 | fences in the kernel. This means:
|
| 294 |
|
| 295 | * No future fences, proxy fences or userspace fences imported as DMA fences,
|
| 296 | with or without a timeout.
|
| 297 |
|
| 298 | * No DMA fences that signal end of batchbuffer for command submission where
|
| 299 | userspace is allowed to use userspace fencing or long running compute
|
| 300 | workloads. This also means no implicit fencing for shared buffers in these
|
| 301 | cases.
|
| 302 |
|
| 303 | Recoverable Hardware Page Faults Implications
|
| 304 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 305 |
|
| 306 | Modern hardware supports recoverable page faults, which has a lot of
|
| 307 | implications for DMA fences.
|
| 308 |
|
| 309 | First, a pending page fault obviously holds up the work that's running on the
|
| 310 | accelerator and a memory allocation is usually required to resolve the fault.
|
| 311 | But memory allocations are not allowed to gate completion of DMA fences, which
|
| 312 | means any workload using recoverable page faults cannot use DMA fences for
|
| 313 | synchronization. Synchronization fences controlled by userspace must be used
|
| 314 | instead.
|
| 315 |
|
| 316 | On GPUs this poses a problem, because current desktop compositor protocols on
|
| 317 | Linux rely on DMA fences, which means without an entirely new userspace stack
|
| 318 | built on top of userspace fences, they cannot benefit from recoverable page
|
| 319 | faults. Specifically this means implicit synchronization will not be possible.
|
| 320 | The exception is when page faults are only used as migration hints and never to
|
| 321 | on-demand fill a memory request. For now this means recoverable page
|
| 322 | faults on GPUs are limited to pure compute workloads.
|
| 323 |
|
| 324 | Furthermore GPUs usually have shared resources between the 3D rendering and
|
| 325 | compute side, like compute units or command submission engines. If both a 3D
|
| 326 | job with a DMA fence and a compute workload using recoverable page faults are
|
| 327 | pending they could deadlock:
|
| 328 |
|
| 329 | - The 3D workload might need to wait for the compute job to finish and release
|
| 330 | hardware resources first.
|
| 331 |
|
| 332 | - The compute workload might be stuck in a page fault, because the memory
|
| 333 | allocation is waiting for the DMA fence of the 3D workload to complete.
|
| 334 |
|
| 335 | There are a few options to prevent this problem, one of which drivers need to
|
| 336 | ensure:
|
| 337 |
|
| 338 | - Compute workloads can always be preempted, even when a page fault is pending
|
| 339 | and not yet repaired. Not all hardware supports this.
|
| 340 |
|
| 341 | - DMA fence workloads and workloads which need page fault handling have
|
| 342 | independent hardware resources to guarantee forward progress. This could be
|
| 343 | achieved through e.g. through dedicated engines and minimal compute unit
|
| 344 | reservations for DMA fence workloads.
|
| 345 |
|
| 346 | - The reservation approach could be further refined by only reserving the
|
| 347 | hardware resources for DMA fence workloads when they are in-flight. This must
|
| 348 | cover the time from when the DMA fence is visible to other threads up to
|
| 349 | moment when fence is completed through dma_fence_signal().
|
| 350 |
|
| 351 | - As a last resort, if the hardware provides no useful reservation mechanics,
|
| 352 | all workloads must be flushed from the GPU when switching between jobs
|
| 353 | requiring DMA fences or jobs requiring page fault handling: This means all DMA
|
| 354 | fences must complete before a compute job with page fault handling can be
|
| 355 | inserted into the scheduler queue. And vice versa, before a DMA fence can be
|
| 356 | made visible anywhere in the system, all compute workloads must be preempted
|
| 357 | to guarantee all pending GPU page faults are flushed.
|
| 358 |
|
| 359 | - Only a fairly theoretical option would be to untangle these dependencies when
|
| 360 | allocating memory to repair hardware page faults, either through separate
|
| 361 | memory blocks or runtime tracking of the full dependency graph of all DMA
|
| 362 | fences. This results very wide impact on the kernel, since resolving the page
|
| 363 | on the CPU side can itself involve a page fault. It is much more feasible and
|
| 364 | robust to limit the impact of handling hardware page faults to the specific
|
| 365 | driver.
|
| 366 |
|
| 367 | Note that workloads that run on independent hardware like copy engines or other
|
| 368 | GPUs do not have any impact. This allows us to keep using DMA fences internally
|
| 369 | in the kernel even for resolving hardware page faults, e.g. by using copy
|
| 370 | engines to clear or copy memory needed to resolve the page fault.
|
| 371 |
|
| 372 | In some ways this page fault problem is a special case of the `Infinite DMA
|
| 373 | Fences` discussions: Infinite fences from compute workloads are allowed to
|
| 374 | depend on DMA fences, but not the other way around. And not even the page fault
|
| 375 | problem is new, because some other CPU thread in userspace might
|
| 376 | hit a page fault which holds up a userspace fence - supporting page faults on
|
| 377 | GPUs doesn't anything fundamentally new.
|