// SPDX-License-Identifier: GPL-2.0-only OR MIT/* * Copyright (c) 2022 Red Hat. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the "Software"), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR * OTHER DEALINGS IN THE SOFTWARE. * * Authors: * Danilo Krummrich <dakr@redhat.com> * */ #include <drm/drm_gpuvm.h> #include <linux/interval_tree_generic.h>#include <linux/mm.h> /** * DOC: Overview * * The DRM GPU VA Manager, represented by struct drm_gpuvm keeps track of a * GPU's virtual address (VA) space and manages the corresponding virtual * mappings represented by &drm_gpuva objects. It also keeps track of the * mapping's backing &drm_gem_object buffers. * * &drm_gem_object buffers maintain a list of &drm_gpuva objects representing * all existent GPU VA mappings using this &drm_gem_object as backing buffer. * * GPU VAs can be flagged as sparse, such that drivers may use GPU VAs to also * keep track of sparse PTEs in order to support Vulkan 'Sparse Resources'. * * The GPU VA manager internally uses a rb-tree to manage the * &drm_gpuva mappings within a GPU's virtual address space. * * The &drm_gpuvm structure contains a special &drm_gpuva representing the * portion of VA space reserved by the kernel. This node is initialized together * with the GPU VA manager instance and removed when the GPU VA manager is * destroyed. * * In a typical application drivers would embed struct drm_gpuvm and * struct drm_gpuva within their own driver specific structures, there won't be * any memory allocations of its own nor memory allocations of &drm_gpuva * entries. * * The data structures needed to store &drm_gpuvas within the &drm_gpuvm are * contained within struct drm_gpuva already. Hence, for inserting &drm_gpuva * entries from within dma-fence signalling critical sections it is enough to * pre-allocate the &drm_gpuva structures. */ /** * DOC: Split and Merge * * Besides its capability to manage and represent a GPU VA space, the * GPU VA manager also provides functions to let the &drm_gpuvm calculate a * sequence of operations to satisfy a given map or unmap request. * * Therefore the DRM GPU VA manager provides an algorithm implementing splitting * and merging of existent GPU VA mappings with the ones that are requested to * be mapped or unmapped. This feature is required by the Vulkan API to * implement Vulkan 'Sparse Memory Bindings' - drivers UAPIs often refer to this * as VM BIND. * * Drivers can call drm_gpuvm_sm_map() to receive a sequence of callbacks * containing map, unmap and remap operations for a given newly requested * mapping. The sequence of callbacks represents the set of operations to * execute in order to integrate the new mapping cleanly into the current state * of the GPU VA space. * * Depending on how the new GPU VA mapping intersects with the existent mappings * of the GPU VA space the &drm_gpuvm_ops callbacks contain an arbitrary amount * of unmap operations, a maximum of two remap operations and a single map * operation. The caller might receive no callback at all if no operation is * required, e.g. if the requested mapping already exists in the exact same way. * * The single map operation represents the original map operation requested by * the caller. * * &drm_gpuva_op_unmap contains a 'keep' field, which indicates whether the * &drm_gpuva to unmap is physically contiguous with the original mapping * request. Optionally, if 'keep' is set, drivers may keep the actual page table * entries for this &drm_gpuva, adding the missing page table entries only and * update the &drm_gpuvm's view of things accordingly. * * Drivers may do the same optimization, namely delta page table updates, also * for remap operations. This is possible since &drm_gpuva_op_remap consists of * one unmap operation and one or two map operations, such that drivers can * derive the page table update delta accordingly. * * Note that there can't be more than two existent mappings to split up, one at * the beginning and one at the end of the new mapping, hence there is a * maximum of two remap operations. * * Analogous to drm_gpuvm_sm_map() drm_gpuvm_sm_unmap() uses &drm_gpuvm_ops to * call back into the driver in order to unmap a range of GPU VA space. The * logic behind this function is way simpler though: For all existent mappings * enclosed by the given range unmap operations are created. For mappings which * are only partically located within the given range, remap operations are * created such that those mappings are split up and re-mapped partically. * * As an alternative to drm_gpuvm_sm_map() and drm_gpuvm_sm_unmap(), * drm_gpuvm_sm_map_ops_create() and drm_gpuvm_sm_unmap_ops_create() can be used * to directly obtain an instance of struct drm_gpuva_ops containing a list of * &drm_gpuva_op, which can be iterated with drm_gpuva_for_each_op(). This list * contains the &drm_gpuva_ops analogous to the callbacks one would receive when * calling drm_gpuvm_sm_map() or drm_gpuvm_sm_unmap(). While this way requires * more memory (to allocate the &drm_gpuva_ops), it provides drivers a way to * iterate the &drm_gpuva_op multiple times, e.g. once in a context where memory * allocations are possible (e.g. to allocate GPU page tables) and once in the * dma-fence signalling critical path. * * To update the &drm_gpuvm's view of the GPU VA space drm_gpuva_insert() and * drm_gpuva_remove() may be used. These functions can safely be used from * &drm_gpuvm_ops callbacks originating from drm_gpuvm_sm_map() or * drm_gpuvm_sm_unmap(). However, it might be more convenient to use the * provided helper functions drm_gpuva_map(), drm_gpuva_remap() and * drm_gpuva_unmap() instead. * * The following diagram depicts the basic relationships of existent GPU VA * mappings, a newly requested mapping and the resulting mappings as implemented * by drm_gpuvm_sm_map() - it doesn't cover any arbitrary combinations of these. * * 1) Requested mapping is identical. Replace it, but indicate the backing PTEs * could be kept. * * :: * * 0 a 1 * old: |-----------| (bo_offset=n) * * 0 a 1 * req: |-----------| (bo_offset=n) * * 0 a 1 * new: |-----------| (bo_offset=n) * * * 2) Requested mapping is identical, except for the BO offset, hence replace * the mapping. * * :: * * 0 a 1 * old: |-----------| (bo_offset=n) * * 0 a 1 * req: |-----------| (bo_offset=m) * * 0 a 1 * new: |-----------| (bo_offset=m) * * * 3) Requested mapping is identical, except for the backing BO, hence replace * the mapping. * * :: * * 0 a 1 * old: |-----------| (bo_offset=n) * * 0 b 1 * req: |-----------| (bo_offset=n) * * 0 b 1 * new: |-----------| (bo_offset=n) * * * 4) Existent mapping is a left aligned subset of the requested one, hence * replace the existent one. * * :: * * 0 a 1 * old: |-----| (bo_offset=n) * * 0 a 2 * req: |-----------| (bo_offset=n) * * 0 a 2 * new: |-----------| (bo_offset=n) * * .. note:: * We expect to see the same result for a request with a different BO * and/or non-contiguous BO offset. * * * 5) Requested mapping's range is a left aligned subset of the existent one, * but backed by a different BO. Hence, map the requested mapping and split * the existent one adjusting its BO offset. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 0 b 1 * req: |-----| (bo_offset=n) * * 0 b 1 a' 2 * new: |-----|-----| (b.bo_offset=n, a.bo_offset=n+1) * * .. note:: * We expect to see the same result for a request with a different BO * and/or non-contiguous BO offset. * * * 6) Existent mapping is a superset of the requested mapping. Split it up, but * indicate that the backing PTEs could be kept. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 0 a 1 * req: |-----| (bo_offset=n) * * 0 a 1 a' 2 * new: |-----|-----| (a.bo_offset=n, a'.bo_offset=n+1) * * * 7) Requested mapping's range is a right aligned subset of the existent one, * but backed by a different BO. Hence, map the requested mapping and split * the existent one, without adjusting the BO offset. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 b 2 * req: |-----| (bo_offset=m) * * 0 a 1 b 2 * new: |-----|-----| (a.bo_offset=n,b.bo_offset=m) * * * 8) Existent mapping is a superset of the requested mapping. Split it up, but * indicate that the backing PTEs could be kept. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 a 2 * req: |-----| (bo_offset=n+1) * * 0 a' 1 a 2 * new: |-----|-----| (a'.bo_offset=n, a.bo_offset=n+1) * * * 9) Existent mapping is overlapped at the end by the requested mapping backed * by a different BO. Hence, map the requested mapping and split up the * existent one, without adjusting the BO offset. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 b 3 * req: |-----------| (bo_offset=m) * * 0 a 1 b 3 * new: |-----|-----------| (a.bo_offset=n,b.bo_offset=m) * * * 10) Existent mapping is overlapped by the requested mapping, both having the * same backing BO with a contiguous offset. Indicate the backing PTEs of * the old mapping could be kept. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 a 3 * req: |-----------| (bo_offset=n+1) * * 0 a' 1 a 3 * new: |-----|-----------| (a'.bo_offset=n, a.bo_offset=n+1) * * * 11) Requested mapping's range is a centered subset of the existent one * having a different backing BO. Hence, map the requested mapping and split * up the existent one in two mappings, adjusting the BO offset of the right * one accordingly. * * :: * * 0 a 3 * old: |-----------------| (bo_offset=n) * * 1 b 2 * req: |-----| (bo_offset=m) * * 0 a 1 b 2 a' 3 * new: |-----|-----|-----| (a.bo_offset=n,b.bo_offset=m,a'.bo_offset=n+2) * * * 12) Requested mapping is a contiguous subset of the existent one. Split it * up, but indicate that the backing PTEs could be kept. * * :: * * 0 a 3 * old: |-----------------| (bo_offset=n) * * 1 a 2 * req: |-----| (bo_offset=n+1) * * 0 a' 1 a 2 a'' 3 * old: |-----|-----|-----| (a'.bo_offset=n, a.bo_offset=n+1, a''.bo_offset=n+2) * * * 13) Existent mapping is a right aligned subset of the requested one, hence * replace the existent one. * * :: * * 1 a 2 * old: |-----| (bo_offset=n+1) * * 0 a 2 * req: |-----------| (bo_offset=n) * * 0 a 2 * new: |-----------| (bo_offset=n) * * .. note:: * We expect to see the same result for a request with a different bo * and/or non-contiguous bo_offset. * * * 14) Existent mapping is a centered subset of the requested one, hence * replace the existent one. * * :: * * 1 a 2 * old: |-----| (bo_offset=n+1) * * 0 a 3 * req: |----------------| (bo_offset=n) * * 0 a 3 * new: |----------------| (bo_offset=n) * * .. note:: * We expect to see the same result for a request with a different bo * and/or non-contiguous bo_offset. * * * 15) Existent mappings is overlapped at the beginning by the requested mapping * backed by a different BO. Hence, map the requested mapping and split up * the existent one, adjusting its BO offset accordingly. * * :: * * 1 a 3 * old: |-----------| (bo_offset=n) * * 0 b 2 * req: |-----------| (bo_offset=m) * * 0 b 2 a' 3 * new: |-----------|-----| (b.bo_offset=m,a.bo_offset=n+2) */ /** * DOC: Locking * * Generally, the GPU VA manager does not take care of locking itself, it is * the drivers responsibility to take care about locking. Drivers might want to * protect the following operations: inserting, removing and iterating * &drm_gpuva objects as well as generating all kinds of operations, such as * split / merge or prefetch. * * The GPU VA manager also does not take care of the locking of the backing * &drm_gem_object buffers GPU VA lists by itself; drivers are responsible to * enforce mutual exclusion using either the GEMs dma_resv lock or alternatively * a driver specific external lock. For the latter see also * drm_gem_gpuva_set_lock(). * * However, the GPU VA manager contains lockdep checks to ensure callers of its * API hold the corresponding lock whenever the &drm_gem_objects GPU VA list is * accessed by functions such as drm_gpuva_link() or drm_gpuva_unlink(). */ /** * DOC: Examples * * This section gives two examples on how to let the DRM GPUVA Manager generate * &drm_gpuva_op in order to satisfy a given map or unmap request and how to * make use of them. * * The below code is strictly limited to illustrate the generic usage pattern. * To maintain simplicitly, it doesn't make use of any abstractions for common * code, different (asyncronous) stages with fence signalling critical paths, * any other helpers or error handling in terms of freeing memory and dropping * previously taken locks. * * 1) Obtain a list of &drm_gpuva_op to create a new mapping:: * * // Allocates a new &drm_gpuva. * struct drm_gpuva * driver_gpuva_alloc(void); * * // Typically drivers would embedd the &drm_gpuvm and &drm_gpuva * // structure in individual driver structures and lock the dma-resv with * // drm_exec or similar helpers. * int driver_mapping_create(struct drm_gpuvm *gpuvm, * u64 addr, u64 range, * struct drm_gem_object *obj, u64 offset) * { * struct drm_gpuva_ops *ops; * struct drm_gpuva_op *op * * driver_lock_va_space(); * ops = drm_gpuvm_sm_map_ops_create(gpuvm, addr, range, * obj, offset); * if (IS_ERR(ops)) * return PTR_ERR(ops); * * drm_gpuva_for_each_op(op, ops) { * struct drm_gpuva *va; * * switch (op->op) { * case DRM_GPUVA_OP_MAP: * va = driver_gpuva_alloc(); * if (!va) * ; // unwind previous VA space updates, * // free memory and unlock * * driver_vm_map(); * drm_gpuva_map(gpuvm, va, &op->map); * drm_gpuva_link(va); * * break; * case DRM_GPUVA_OP_REMAP: { * struct drm_gpuva *prev = NULL, *next = NULL; * * va = op->remap.unmap->va; * * if (op->remap.prev) { * prev = driver_gpuva_alloc(); * if (!prev) * ; // unwind previous VA space * // updates, free memory and * // unlock * } * * if (op->remap.next) { * next = driver_gpuva_alloc(); * if (!next) * ; // unwind previous VA space * // updates, free memory and * // unlock * } * * driver_vm_remap(); * drm_gpuva_remap(prev, next, &op->remap); * * drm_gpuva_unlink(va); * if (prev) * drm_gpuva_link(prev); * if (next) * drm_gpuva_link(next); * * break; * } * case DRM_GPUVA_OP_UNMAP: * va = op->unmap->va; * * driver_vm_unmap(); * drm_gpuva_unlink(va); * drm_gpuva_unmap(&op->unmap); * * break; * default: * break; * } * } * driver_unlock_va_space(); *Lines 1–500 of 1726. Load more
// SPDX-License-Identifier: GPL-2.0-only OR MIT /* * Copyright (c) 2022 Red Hat. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the "Software"), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR * OTHER DEALINGS IN THE SOFTWARE. * * Authors: * Danilo Krummrich <dakr@redhat.com> * */ #include <drm/drm_gpuvm.h> #include <linux/interval_tree_generic.h> #include <linux/mm.h> /** * DOC: Overview * * The DRM GPU VA Manager, represented by struct drm_gpuvm keeps track of a * GPU's virtual address (VA) space and manages the corresponding virtual * mappings represented by &drm_gpuva objects. It also keeps track of the * mapping's backing &drm_gem_object buffers. * * &drm_gem_object buffers maintain a list of &drm_gpuva objects representing * all existent GPU VA mappings using this &drm_gem_object as backing buffer. * * GPU VAs can be flagged as sparse, such that drivers may use GPU VAs to also * keep track of sparse PTEs in order to support Vulkan 'Sparse Resources'. * * The GPU VA manager internally uses a rb-tree to manage the * &drm_gpuva mappings within a GPU's virtual address space. * * The &drm_gpuvm structure contains a special &drm_gpuva representing the * portion of VA space reserved by the kernel. This node is initialized together * with the GPU VA manager instance and removed when the GPU VA manager is * destroyed. * * In a typical application drivers would embed struct drm_gpuvm and * struct drm_gpuva within their own driver specific structures, there won't be * any memory allocations of its own nor memory allocations of &drm_gpuva * entries. * * The data structures needed to store &drm_gpuvas within the &drm_gpuvm are * contained within struct drm_gpuva already. Hence, for inserting &drm_gpuva * entries from within dma-fence signalling critical sections it is enough to * pre-allocate the &drm_gpuva structures. */ /** * DOC: Split and Merge * * Besides its capability to manage and represent a GPU VA space, the * GPU VA manager also provides functions to let the &drm_gpuvm calculate a * sequence of operations to satisfy a given map or unmap request. * * Therefore the DRM GPU VA manager provides an algorithm implementing splitting * and merging of existent GPU VA mappings with the ones that are requested to * be mapped or unmapped. This feature is required by the Vulkan API to * implement Vulkan 'Sparse Memory Bindings' - drivers UAPIs often refer to this * as VM BIND. * * Drivers can call drm_gpuvm_sm_map() to receive a sequence of callbacks * containing map, unmap and remap operations for a given newly requested * mapping. The sequence of callbacks represents the set of operations to * execute in order to integrate the new mapping cleanly into the current state * of the GPU VA space. * * Depending on how the new GPU VA mapping intersects with the existent mappings * of the GPU VA space the &drm_gpuvm_ops callbacks contain an arbitrary amount * of unmap operations, a maximum of two remap operations and a single map * operation. The caller might receive no callback at all if no operation is * required, e.g. if the requested mapping already exists in the exact same way. * * The single map operation represents the original map operation requested by * the caller. * * &drm_gpuva_op_unmap contains a 'keep' field, which indicates whether the * &drm_gpuva to unmap is physically contiguous with the original mapping * request. Optionally, if 'keep' is set, drivers may keep the actual page table * entries for this &drm_gpuva, adding the missing page table entries only and * update the &drm_gpuvm's view of things accordingly. * * Drivers may do the same optimization, namely delta page table updates, also * for remap operations. This is possible since &drm_gpuva_op_remap consists of * one unmap operation and one or two map operations, such that drivers can * derive the page table update delta accordingly. * * Note that there can't be more than two existent mappings to split up, one at * the beginning and one at the end of the new mapping, hence there is a * maximum of two remap operations. * * Analogous to drm_gpuvm_sm_map() drm_gpuvm_sm_unmap() uses &drm_gpuvm_ops to * call back into the driver in order to unmap a range of GPU VA space. The * logic behind this function is way simpler though: For all existent mappings * enclosed by the given range unmap operations are created. For mappings which * are only partically located within the given range, remap operations are * created such that those mappings are split up and re-mapped partically. * * As an alternative to drm_gpuvm_sm_map() and drm_gpuvm_sm_unmap(), * drm_gpuvm_sm_map_ops_create() and drm_gpuvm_sm_unmap_ops_create() can be used * to directly obtain an instance of struct drm_gpuva_ops containing a list of * &drm_gpuva_op, which can be iterated with drm_gpuva_for_each_op(). This list * contains the &drm_gpuva_ops analogous to the callbacks one would receive when * calling drm_gpuvm_sm_map() or drm_gpuvm_sm_unmap(). While this way requires * more memory (to allocate the &drm_gpuva_ops), it provides drivers a way to * iterate the &drm_gpuva_op multiple times, e.g. once in a context where memory * allocations are possible (e.g. to allocate GPU page tables) and once in the * dma-fence signalling critical path. * * To update the &drm_gpuvm's view of the GPU VA space drm_gpuva_insert() and * drm_gpuva_remove() may be used. These functions can safely be used from * &drm_gpuvm_ops callbacks originating from drm_gpuvm_sm_map() or * drm_gpuvm_sm_unmap(). However, it might be more convenient to use the * provided helper functions drm_gpuva_map(), drm_gpuva_remap() and * drm_gpuva_unmap() instead. * * The following diagram depicts the basic relationships of existent GPU VA * mappings, a newly requested mapping and the resulting mappings as implemented * by drm_gpuvm_sm_map() - it doesn't cover any arbitrary combinations of these. * * 1) Requested mapping is identical. Replace it, but indicate the backing PTEs * could be kept. * * :: * * 0 a 1 * old: |-----------| (bo_offset=n) * * 0 a 1 * req: |-----------| (bo_offset=n) * * 0 a 1 * new: |-----------| (bo_offset=n) * * * 2) Requested mapping is identical, except for the BO offset, hence replace * the mapping. * * :: * * 0 a 1 * old: |-----------| (bo_offset=n) * * 0 a 1 * req: |-----------| (bo_offset=m) * * 0 a 1 * new: |-----------| (bo_offset=m) * * * 3) Requested mapping is identical, except for the backing BO, hence replace * the mapping. * * :: * * 0 a 1 * old: |-----------| (bo_offset=n) * * 0 b 1 * req: |-----------| (bo_offset=n) * * 0 b 1 * new: |-----------| (bo_offset=n) * * * 4) Existent mapping is a left aligned subset of the requested one, hence * replace the existent one. * * :: * * 0 a 1 * old: |-----| (bo_offset=n) * * 0 a 2 * req: |-----------| (bo_offset=n) * * 0 a 2 * new: |-----------| (bo_offset=n) * * .. note:: * We expect to see the same result for a request with a different BO * and/or non-contiguous BO offset. * * * 5) Requested mapping's range is a left aligned subset of the existent one, * but backed by a different BO. Hence, map the requested mapping and split * the existent one adjusting its BO offset. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 0 b 1 * req: |-----| (bo_offset=n) * * 0 b 1 a' 2 * new: |-----|-----| (b.bo_offset=n, a.bo_offset=n+1) * * .. note:: * We expect to see the same result for a request with a different BO * and/or non-contiguous BO offset. * * * 6) Existent mapping is a superset of the requested mapping. Split it up, but * indicate that the backing PTEs could be kept. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 0 a 1 * req: |-----| (bo_offset=n) * * 0 a 1 a' 2 * new: |-----|-----| (a.bo_offset=n, a'.bo_offset=n+1) * * * 7) Requested mapping's range is a right aligned subset of the existent one, * but backed by a different BO. Hence, map the requested mapping and split * the existent one, without adjusting the BO offset. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 b 2 * req: |-----| (bo_offset=m) * * 0 a 1 b 2 * new: |-----|-----| (a.bo_offset=n,b.bo_offset=m) * * * 8) Existent mapping is a superset of the requested mapping. Split it up, but * indicate that the backing PTEs could be kept. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 a 2 * req: |-----| (bo_offset=n+1) * * 0 a' 1 a 2 * new: |-----|-----| (a'.bo_offset=n, a.bo_offset=n+1) * * * 9) Existent mapping is overlapped at the end by the requested mapping backed * by a different BO. Hence, map the requested mapping and split up the * existent one, without adjusting the BO offset. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 b 3 * req: |-----------| (bo_offset=m) * * 0 a 1 b 3 * new: |-----|-----------| (a.bo_offset=n,b.bo_offset=m) * * * 10) Existent mapping is overlapped by the requested mapping, both having the * same backing BO with a contiguous offset. Indicate the backing PTEs of * the old mapping could be kept. * * :: * * 0 a 2 * old: |-----------| (bo_offset=n) * * 1 a 3 * req: |-----------| (bo_offset=n+1) * * 0 a' 1 a 3 * new: |-----|-----------| (a'.bo_offset=n, a.bo_offset=n+1) * * * 11) Requested mapping's range is a centered subset of the existent one * having a different backing BO. Hence, map the requested mapping and split * up the existent one in two mappings, adjusting the BO offset of the right * one accordingly. * * :: * * 0 a 3 * old: |-----------------| (bo_offset=n) * * 1 b 2 * req: |-----| (bo_offset=m) * * 0 a 1 b 2 a' 3 * new: |-----|-----|-----| (a.bo_offset=n,b.bo_offset=m,a'.bo_offset=n+2) * * * 12) Requested mapping is a contiguous subset of the existent one. Split it * up, but indicate that the backing PTEs could be kept. * * :: * * 0 a 3 * old: |-----------------| (bo_offset=n) * * 1 a 2 * req: |-----| (bo_offset=n+1) * * 0 a' 1 a 2 a'' 3 * old: |-----|-----|-----| (a'.bo_offset=n, a.bo_offset=n+1, a''.bo_offset=n+2) * * * 13) Existent mapping is a right aligned subset of the requested one, hence * replace the existent one. * * :: * * 1 a 2 * old: |-----| (bo_offset=n+1) * * 0 a 2 * req: |-----------| (bo_offset=n) * * 0 a 2 * new: |-----------| (bo_offset=n) * * .. note:: * We expect to see the same result for a request with a different bo * and/or non-contiguous bo_offset. * * * 14) Existent mapping is a centered subset of the requested one, hence * replace the existent one. * * :: * * 1 a 2 * old: |-----| (bo_offset=n+1) * * 0 a 3 * req: |----------------| (bo_offset=n) * * 0 a 3 * new: |----------------| (bo_offset=n) * * .. note:: * We expect to see the same result for a request with a different bo * and/or non-contiguous bo_offset. * * * 15) Existent mappings is overlapped at the beginning by the requested mapping * backed by a different BO. Hence, map the requested mapping and split up * the existent one, adjusting its BO offset accordingly. * * :: * * 1 a 3 * old: |-----------| (bo_offset=n) * * 0 b 2 * req: |-----------| (bo_offset=m) * * 0 b 2 a' 3 * new: |-----------|-----| (b.bo_offset=m,a.bo_offset=n+2) */ /** * DOC: Locking * * Generally, the GPU VA manager does not take care of locking itself, it is * the drivers responsibility to take care about locking. Drivers might want to * protect the following operations: inserting, removing and iterating * &drm_gpuva objects as well as generating all kinds of operations, such as * split / merge or prefetch. * * The GPU VA manager also does not take care of the locking of the backing * &drm_gem_object buffers GPU VA lists by itself; drivers are responsible to * enforce mutual exclusion using either the GEMs dma_resv lock or alternatively * a driver specific external lock. For the latter see also * drm_gem_gpuva_set_lock(). * * However, the GPU VA manager contains lockdep checks to ensure callers of its * API hold the corresponding lock whenever the &drm_gem_objects GPU VA list is * accessed by functions such as drm_gpuva_link() or drm_gpuva_unlink(). */ /** * DOC: Examples * * This section gives two examples on how to let the DRM GPUVA Manager generate * &drm_gpuva_op in order to satisfy a given map or unmap request and how to * make use of them. * * The below code is strictly limited to illustrate the generic usage pattern. * To maintain simplicitly, it doesn't make use of any abstractions for common * code, different (asyncronous) stages with fence signalling critical paths, * any other helpers or error handling in terms of freeing memory and dropping * previously taken locks. * * 1) Obtain a list of &drm_gpuva_op to create a new mapping:: * * // Allocates a new &drm_gpuva. * struct drm_gpuva * driver_gpuva_alloc(void); * * // Typically drivers would embedd the &drm_gpuvm and &drm_gpuva * // structure in individual driver structures and lock the dma-resv with * // drm_exec or similar helpers. * int driver_mapping_create(struct drm_gpuvm *gpuvm, * u64 addr, u64 range, * struct drm_gem_object *obj, u64 offset) * { * struct drm_gpuva_ops *ops; * struct drm_gpuva_op *op * * driver_lock_va_space(); * ops = drm_gpuvm_sm_map_ops_create(gpuvm, addr, range, * obj, offset); * if (IS_ERR(ops)) * return PTR_ERR(ops); * * drm_gpuva_for_each_op(op, ops) { * struct drm_gpuva *va; * * switch (op->op) { * case DRM_GPUVA_OP_MAP: * va = driver_gpuva_alloc(); * if (!va) * ; // unwind previous VA space updates, * // free memory and unlock * * driver_vm_map(); * drm_gpuva_map(gpuvm, va, &op->map); * drm_gpuva_link(va); * * break; * case DRM_GPUVA_OP_REMAP: { * struct drm_gpuva *prev = NULL, *next = NULL; * * va = op->remap.unmap->va; * * if (op->remap.prev) { * prev = driver_gpuva_alloc(); * if (!prev) * ; // unwind previous VA space * // updates, free memory and * // unlock * } * * if (op->remap.next) { * next = driver_gpuva_alloc(); * if (!next) * ; // unwind previous VA space * // updates, free memory and * // unlock * } * * driver_vm_remap(); * drm_gpuva_remap(prev, next, &op->remap); * * drm_gpuva_unlink(va); * if (prev) * drm_gpuva_link(prev); * if (next) * drm_gpuva_link(next); * * break; * } * case DRM_GPUVA_OP_UNMAP: * va = op->unmap->va; * * driver_vm_unmap(); * drm_gpuva_unlink(va); * drm_gpuva_unmap(&op->unmap); * * break; * default: * break; * } * } * driver_unlock_va_space(); *