diff mbox series

[drm-next,v5,03/14] drm: manager to keep track of GPUs VA mappings

Message ID 20230620004217.4700-4-dakr@redhat.com (mailing list archive)
State New
Headers show
Series DRM GPUVA Manager & Nouveau VM_BIND UAPI | expand

Commit Message

Danilo Krummrich June 20, 2023, 12:42 a.m. UTC
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.

New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start implementing, allow userspace applications to request multiple and
arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is
intended to serve the following purposes in this context.

1) Provide infrastructure to track GPU VA allocations and mappings,
   making use of the maple_tree.

2) Generically connect GPU VA mappings to their backing buffers, in
   particular DRM GEM objects.

3) Provide a common implementation to perform more complex mapping
   operations on the GPU VA space. In particular splitting and merging
   of GPU VA mappings, e.g. for intersecting mapping requests or partial
   unmap requests.

Tested-by: Donald Robson <donald.robson@imgtec.com>
Suggested-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
---
 Documentation/gpu/drm-mm.rst    |   42 +
 drivers/gpu/drm/Makefile        |    1 +
 drivers/gpu/drm/drm_gem.c       |    3 +
 drivers/gpu/drm/drm_gpuva_mgr.c | 1971 +++++++++++++++++++++++++++++++
 include/drm/drm_drv.h           |    6 +
 include/drm/drm_gem.h           |   52 +
 include/drm/drm_gpuva_mgr.h     |  682 +++++++++++
 7 files changed, 2757 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c
 create mode 100644 include/drm/drm_gpuva_mgr.h

Comments

kernel test robot June 20, 2023, 3 a.m. UTC | #1
Hi Danilo,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 2222dcb0775d36de28992f56455ab3967b30d380]

url:    https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230620-084448
base:   2222dcb0775d36de28992f56455ab3967b30d380
patch link:    https://lore.kernel.org/r/20230620004217.4700-4-dakr%40redhat.com
patch subject: [PATCH drm-next v5 03/14] drm: manager to keep track of GPUs VA mappings
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20230620/202306201034.GucldV3r-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 12.3.0
reproduce: (https://download.01.org/0day-ci/archive/20230620/202306201034.GucldV3r-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202306201034.GucldV3r-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from arch/m68k/include/asm/bug.h:32,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:13,
                    from include/asm-generic/preempt.h:5,
                    from ./arch/m68k/include/generated/asm/preempt.h:1,
                    from include/linux/preempt.h:78,
                    from include/linux/spinlock.h:56,
                    from include/linux/kref.h:16,
                    from include/drm/drm_gem.h:37,
                    from drivers/gpu/drm/drm_gpuva_mgr.c:28:
   drivers/gpu/drm/drm_gpuva_mgr.c: In function 'drm_gpuva_check_overflow':
>> drivers/gpu/drm/drm_gpuva_mgr.c:675:21: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Wformat=]
     675 |                     "GPUVA address limited to %lu bytes, see Documentation.\n",
         |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/asm-generic/bug.h:97:62: note: in definition of macro '__WARN_printf'
      97 |                 warn_slowpath_fmt(__FILE__, __LINE__, taint, arg);      \
         |                                                              ^~~
   drivers/gpu/drm/drm_gpuva_mgr.c:674:16: note: in expansion of macro 'WARN'
     674 |         return WARN(check_add_overflow(addr, range, &end),
         |                ^~~~
   drivers/gpu/drm/drm_gpuva_mgr.c:675:49: note: format string is defined here
     675 |                     "GPUVA address limited to %lu bytes, see Documentation.\n",
         |                                               ~~^
         |                                                 |
         |                                                 long unsigned int
         |                                               %u
   drivers/gpu/drm/drm_gpuva_mgr.c: In function '__drm_gpuva_sm_map':
   drivers/gpu/drm/drm_gpuva_mgr.c:1314:32: warning: variable 'prev' set but not used [-Wunused-but-set-variable]
    1314 |         struct drm_gpuva *va, *prev = NULL;
         |                                ^~~~


vim +675 drivers/gpu/drm/drm_gpuva_mgr.c

   668	
   669	static inline bool
   670	drm_gpuva_check_overflow(u64 addr, u64 range)
   671	{
   672		MTREE_INDEX_TYPE end;
   673	
   674		return WARN(check_add_overflow(addr, range, &end),
 > 675			    "GPUVA address limited to %lu bytes, see Documentation.\n",
   676			    MTREE_INDEX_SIZE);
   677	}
   678
kernel test robot June 20, 2023, 3:32 a.m. UTC | #2
Hi Danilo,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 2222dcb0775d36de28992f56455ab3967b30d380]

url:    https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230620-084448
base:   2222dcb0775d36de28992f56455ab3967b30d380
patch link:    https://lore.kernel.org/r/20230620004217.4700-4-dakr%40redhat.com
patch subject: [PATCH drm-next v5 03/14] drm: manager to keep track of GPUs VA mappings
config: hexagon-randconfig-r041-20230620 (https://download.01.org/0day-ci/archive/20230620/202306201123.4nvLB3cQ-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce: (https://download.01.org/0day-ci/archive/20230620/202306201123.4nvLB3cQ-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202306201123.4nvLB3cQ-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/drm_gpuva_mgr.c:676:7: warning: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Wformat]
     676 |         return WARN(check_add_overflow(addr, range, &end),
         |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     677 |                     "GPUVA address limited to %lu bytes, see Documentation.\n",
         |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         |                                               %u
     678 |                     MTREE_INDEX_SIZE);
         |                     ^~~~~~~~~~~~~~~~~
   drivers/gpu/drm/drm_gpuva_mgr.c:663:26: note: expanded from macro 'MTREE_INDEX_SIZE'
     663 | #define MTREE_INDEX_SIZE sizeof(MTREE_INDEX_TYPE)
         |                          ^
   include/asm-generic/bug.h:133:29: note: expanded from macro 'WARN'
     133 |                 __WARN_printf(TAINT_WARN, format);                      \
         |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
   include/asm-generic/bug.h:97:48: note: expanded from macro '__WARN_printf'
      97 |                 warn_slowpath_fmt(__FILE__, __LINE__, taint, arg);      \
         |                                                              ^~~
   drivers/gpu/drm/drm_gpuva_mgr.c:1314:25: warning: variable 'prev' set but not used [-Wunused-but-set-variable]
    1314 |         struct drm_gpuva *va, *prev = NULL;
         |                                ^
   2 warnings generated.


vim +676 drivers/gpu/drm/drm_gpuva_mgr.c

   668	
   669	static inline bool
   670	drm_gpuva_check_overflow(u64 addr, u64 range)
   671	{
   672		MTREE_INDEX_TYPE end;
   673	
   674		return WARN(check_add_overflow(addr, range, &end),
   675			    "GPUVA address limited to %lu bytes, see Documentation.\n",
 > 676			    MTREE_INDEX_SIZE);
   677	}
   678
Christoph Hellwig June 20, 2023, 4:54 a.m. UTC | #3
Why are none of these EXPORT_SYMBOL_GPL as it's very linux-internal
stuff?
Christian König June 20, 2023, 6:45 a.m. UTC | #4
Hi Danilo,

sorry for the delayed reply. I've trying to dig myself out of a hole at 
the moment.

Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
> [SNIP]
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index bbc721870c13..5ec8148a30ee 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -36,6 +36,8 @@
>   
>   #include <linux/kref.h>
>   #include <linux/dma-resv.h>
> +#include <linux/list.h>
> +#include <linux/mutex.h>
>   
>   #include <drm/drm_vma_manager.h>
>   
> @@ -379,6 +381,18 @@ struct drm_gem_object {
>   	 */
>   	struct dma_resv _resv;
>   
> +	/**
> +	 * @gpuva:
> +	 *
> +	 * Provides the list of GPU VAs attached to this GEM object.
> +	 *
> +	 * Drivers should lock list accesses with the GEMs &dma_resv lock
> +	 * (&drm_gem_object.resv).
> +	 */
> +	struct {
> +		struct list_head list;
> +	} gpuva;
> +
>   	/**
>   	 * @funcs:
>   	 *

I'm pretty sure that it's not a good idea to attach this directly to the 
GEM object.

As you wrote in the commit message it's highly driver specific what to 
map and where to map it.

Instead I suggest to have a separate structure for mappings in a VA 
space which driver can then add to their GEM objects or whatever they 
want to map into their VMs.

Regards,
Christian.
Danilo Krummrich June 20, 2023, 12:23 p.m. UTC | #5
Hi Christian,

On 6/20/23 08:45, Christian König wrote:
> Hi Danilo,
> 
> sorry for the delayed reply. I've trying to dig myself out of a hole at 
> the moment.

No worries, thank you for taking a look anyway!

> 
> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>> [SNIP]
>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>> index bbc721870c13..5ec8148a30ee 100644
>> --- a/include/drm/drm_gem.h
>> +++ b/include/drm/drm_gem.h
>> @@ -36,6 +36,8 @@
>>   #include <linux/kref.h>
>>   #include <linux/dma-resv.h>
>> +#include <linux/list.h>
>> +#include <linux/mutex.h>
>>   #include <drm/drm_vma_manager.h>
>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>        */
>>       struct dma_resv _resv;
>> +    /**
>> +     * @gpuva:
>> +     *
>> +     * Provides the list of GPU VAs attached to this GEM object.
>> +     *
>> +     * Drivers should lock list accesses with the GEMs &dma_resv lock
>> +     * (&drm_gem_object.resv).
>> +     */
>> +    struct {
>> +        struct list_head list;
>> +    } gpuva;
>> +
>>       /**
>>        * @funcs:
>>        *
> 
> I'm pretty sure that it's not a good idea to attach this directly to the 
> GEM object.

Why do you think so? IMHO having a common way to connect mappings to 
their backing buffers is a good thing, since every driver needs this 
connection anyway.

E.g. when a BO gets evicted, drivers can just iterate the list of 
mappings and, as the circumstances require, invalidate the corresponding 
mappings or to unmap all existing mappings of a given buffer.

What would be the advantage to let every driver implement a driver 
specific way of keeping this connection? Do you see cases where this 
kind of connection between mappings and backing buffers wouldn't be good 
enough? If so, which cases do you have in mind? Maybe we can cover them 
in a common way as well?

> 
> As you wrote in the commit message it's highly driver specific what to 
> map and where to map it.

In the end the common case should be that in a VA space at least every 
mapping being backed by a BO is represented by a struct drm_gpuva.

> 
> Instead I suggest to have a separate structure for mappings in a VA 
> space which driver can then add to their GEM objects or whatever they 
> want to map into their VMs.

Which kind of separate structure for mappings? Another one analogous to 
struct drm_gpuva?

- Danilo

> 
> Regards,
> Christian.
> 
>
Donald Robson June 21, 2023, 6:58 p.m. UTC | #6
Hi Danilo,
One comment below, but otherwise it looks great.  Thanks for adding the example!
Thanks,
Donald

On Tue, 2023-06-20 at 02:42 +0200, Danilo Krummrich wrote:
> 
> +/**
> + * DOC: Overview
> + *
> + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager 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 &maple_tree to manage the
> + * &drm_gpuva mappings within a GPU's virtual address space.
> + *
> + * The &drm_gpuva_manager 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_gpuva_manager and
> + * struct drm_gpuva within their own driver specific structures, there won't be
> + * any memory allocations of it's own nor memory allocations of &drm_gpuva
> + * entries.
> + *
> + * However, the &drm_gpuva_manager needs to allocate nodes for it's internal
> + * tree structures when &drm_gpuva entries are inserted. In order to support
> + * inserting &drm_gpuva entries from dma-fence signalling critical sections the
> + * &drm_gpuva_manager provides struct drm_gpuva_prealloc. Drivers may create
> + * pre-allocated nodes which drm_gpuva_prealloc_create() and subsequently insert
> + * a new &drm_gpuva entry with drm_gpuva_insert_prealloc().

I think it might be worth moving or repeating this paragraph to 'Split and Merge'
where I've added the other comment below.  I think these functions are only used
to set up for drm_gpuva_sm_map().  Please ignore me if I'm wrong.

> + */
> +
> +/**
> + * DOC: Split and Merge
> + *
> + * Besides it's capability to manage and represent a GPU VA space, the
> + * &drm_gpuva_manager also provides functions to let the &drm_gpuva_manager
> + * 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_gpuva_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.

Here

> + *
> + * Depending on how the new GPU VA mapping intersects with the existent mappings
> + * of the GPU VA space the &drm_gpuva_fn_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.
>
Christian König June 22, 2023, 1:54 p.m. UTC | #7
Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
> Hi Christian,
>
> On 6/20/23 08:45, Christian König wrote:
>> Hi Danilo,
>>
>> sorry for the delayed reply. I've trying to dig myself out of a hole 
>> at the moment.
>
> No worries, thank you for taking a look anyway!
>
>>
>> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>>> [SNIP]
>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>> index bbc721870c13..5ec8148a30ee 100644
>>> --- a/include/drm/drm_gem.h
>>> +++ b/include/drm/drm_gem.h
>>> @@ -36,6 +36,8 @@
>>>   #include <linux/kref.h>
>>>   #include <linux/dma-resv.h>
>>> +#include <linux/list.h>
>>> +#include <linux/mutex.h>
>>>   #include <drm/drm_vma_manager.h>
>>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>>        */
>>>       struct dma_resv _resv;
>>> +    /**
>>> +     * @gpuva:
>>> +     *
>>> +     * Provides the list of GPU VAs attached to this GEM object.
>>> +     *
>>> +     * Drivers should lock list accesses with the GEMs &dma_resv lock
>>> +     * (&drm_gem_object.resv).
>>> +     */
>>> +    struct {
>>> +        struct list_head list;
>>> +    } gpuva;
>>> +
>>>       /**
>>>        * @funcs:
>>>        *
>>
>> I'm pretty sure that it's not a good idea to attach this directly to 
>> the GEM object.
>
> Why do you think so? IMHO having a common way to connect mappings to 
> their backing buffers is a good thing, since every driver needs this 
> connection anyway.
>
> E.g. when a BO gets evicted, drivers can just iterate the list of 
> mappings and, as the circumstances require, invalidate the 
> corresponding mappings or to unmap all existing mappings of a given 
> buffer.
>
> What would be the advantage to let every driver implement a driver 
> specific way of keeping this connection?

Flexibility. For example on amdgpu the mappings of a BO are groups by VM 
address spaces.

E.g. the BO points to multiple bo_vm structures which in turn have lists 
of their mappings.

Additional to that there is a state maschine associated with the 
mappings, e.g. if the page tables are up to date or need to be updated 
etc....

> Do you see cases where this kind of connection between mappings and 
> backing buffers wouldn't be good enough? If so, which cases do you 
> have in mind? Maybe we can cover them in a common way as well?

Yeah, we have tons of cases like that. But I have no idea how to 
generalize them.

>
>>
>> As you wrote in the commit message it's highly driver specific what 
>> to map and where to map it.
>
> In the end the common case should be that in a VA space at least every 
> mapping being backed by a BO is represented by a struct drm_gpuva.

Oh, no! We also have mappings not backed by a BO at all! For example for 
partial resident textures or data routing to internal hw etc...

You can't be sure that a mapping is backed by a BO at all.

>
>>
>> Instead I suggest to have a separate structure for mappings in a VA 
>> space which driver can then add to their GEM objects or whatever they 
>> want to map into their VMs.
>
> Which kind of separate structure for mappings? Another one analogous 
> to struct drm_gpuva?

Well similar to what amdgpu uses BO -> one structure for each 
combination of BO and VM -> mappings inside that VM

Regards,
Christian.

>
> - Danilo
>
>>
>> Regards,
>> Christian.
>>
>>
>
Danilo Krummrich June 22, 2023, 2:22 p.m. UTC | #8
On 6/22/23 15:54, Christian König wrote:
> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
>> Hi Christian,
>>
>> On 6/20/23 08:45, Christian König wrote:
>>> Hi Danilo,
>>>
>>> sorry for the delayed reply. I've trying to dig myself out of a hole 
>>> at the moment.
>>
>> No worries, thank you for taking a look anyway!
>>
>>>
>>> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>>>> [SNIP]
>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>> index bbc721870c13..5ec8148a30ee 100644
>>>> --- a/include/drm/drm_gem.h
>>>> +++ b/include/drm/drm_gem.h
>>>> @@ -36,6 +36,8 @@
>>>>   #include <linux/kref.h>
>>>>   #include <linux/dma-resv.h>
>>>> +#include <linux/list.h>
>>>> +#include <linux/mutex.h>
>>>>   #include <drm/drm_vma_manager.h>
>>>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>>>        */
>>>>       struct dma_resv _resv;
>>>> +    /**
>>>> +     * @gpuva:
>>>> +     *
>>>> +     * Provides the list of GPU VAs attached to this GEM object.
>>>> +     *
>>>> +     * Drivers should lock list accesses with the GEMs &dma_resv lock
>>>> +     * (&drm_gem_object.resv).
>>>> +     */
>>>> +    struct {
>>>> +        struct list_head list;
>>>> +    } gpuva;
>>>> +
>>>>       /**
>>>>        * @funcs:
>>>>        *
>>>
>>> I'm pretty sure that it's not a good idea to attach this directly to 
>>> the GEM object.
>>
>> Why do you think so? IMHO having a common way to connect mappings to 
>> their backing buffers is a good thing, since every driver needs this 
>> connection anyway.
>>
>> E.g. when a BO gets evicted, drivers can just iterate the list of 
>> mappings and, as the circumstances require, invalidate the 
>> corresponding mappings or to unmap all existing mappings of a given 
>> buffer.
>>
>> What would be the advantage to let every driver implement a driver 
>> specific way of keeping this connection?
> 
> Flexibility. For example on amdgpu the mappings of a BO are groups by VM 
> address spaces.
> 
> E.g. the BO points to multiple bo_vm structures which in turn have lists 
> of their mappings.

Isn't this (almost) the same relationship I introduce with the GPUVA 
manager?

If you would switch over to the GPUVA manager right now, it would be 
that every GEM has a list of it's mappings (the gpuva list). The mapping 
is represented by struct drm_gpuva (of course embedded in driver 
specific structure(s)) which has a pointer to the VM address space it is 
part of, namely the GPUVA manager instance. And the GPUVA manager keeps 
a maple tree of it's mappings as well.

If you still would like to *directly* (indirectly you already have that 
relationship) keep a list of GPUVA managers (VM address spaces) per GEM, 
you could still do that in a driver specific way.

Do I miss something?

> 
> Additional to that there is a state maschine associated with the 
> mappings, e.g. if the page tables are up to date or need to be updated 
> etc....
> 
>> Do you see cases where this kind of connection between mappings and 
>> backing buffers wouldn't be good enough? If so, which cases do you 
>> have in mind? Maybe we can cover them in a common way as well?
> 
> Yeah, we have tons of cases like that. But I have no idea how to 
> generalize them.

They could still remain to be driver specific then, right?

> 
>>
>>>
>>> As you wrote in the commit message it's highly driver specific what 
>>> to map and where to map it.
>>
>> In the end the common case should be that in a VA space at least every 
>> mapping being backed by a BO is represented by a struct drm_gpuva.
> 
> Oh, no! We also have mappings not backed by a BO at all! For example for 
> partial resident textures or data routing to internal hw etc...
> 
> You can't be sure that a mapping is backed by a BO at all.

I fully agree, that's why I wrote "the common case should be that in a 
VA space at least every mapping *being backed by a BO* is represented by 
a struct drm_gpuva".

Mappings not being backed by an actual BO would not be linked to a GEM 
of course.

> 
>>
>>>
>>> Instead I suggest to have a separate structure for mappings in a VA 
>>> space which driver can then add to their GEM objects or whatever they 
>>> want to map into their VMs.
>>
>> Which kind of separate structure for mappings? Another one analogous 
>> to struct drm_gpuva?
> 
> Well similar to what amdgpu uses BO -> one structure for each 
> combination of BO and VM -> mappings inside that VM

As explained above, I think that's exactly what the GPUVA manager does, 
just in another order:

BO has list of mappings, mappings have pointer to VM, VM has list (or 
actually a maple tree) of mappings.

You see any advantages or disadvantages of either order of 
relationships? For me it looks like it doesn't really matter which one 
to pick.

- Danilo

> 
> Regards,
> Christian.
> 
>>
>> - Danilo
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>
>>
>
Christian König June 22, 2023, 2:42 p.m. UTC | #9
Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
> On 6/22/23 15:54, Christian König wrote:
>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
>>> Hi Christian,
>>>
>>> On 6/20/23 08:45, Christian König wrote:
>>>> Hi Danilo,
>>>>
>>>> sorry for the delayed reply. I've trying to dig myself out of a 
>>>> hole at the moment.
>>>
>>> No worries, thank you for taking a look anyway!
>>>
>>>>
>>>> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>>>>> [SNIP]
>>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>>> index bbc721870c13..5ec8148a30ee 100644
>>>>> --- a/include/drm/drm_gem.h
>>>>> +++ b/include/drm/drm_gem.h
>>>>> @@ -36,6 +36,8 @@
>>>>>   #include <linux/kref.h>
>>>>>   #include <linux/dma-resv.h>
>>>>> +#include <linux/list.h>
>>>>> +#include <linux/mutex.h>
>>>>>   #include <drm/drm_vma_manager.h>
>>>>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>>>>        */
>>>>>       struct dma_resv _resv;
>>>>> +    /**
>>>>> +     * @gpuva:
>>>>> +     *
>>>>> +     * Provides the list of GPU VAs attached to this GEM object.
>>>>> +     *
>>>>> +     * Drivers should lock list accesses with the GEMs &dma_resv 
>>>>> lock
>>>>> +     * (&drm_gem_object.resv).
>>>>> +     */
>>>>> +    struct {
>>>>> +        struct list_head list;
>>>>> +    } gpuva;
>>>>> +
>>>>>       /**
>>>>>        * @funcs:
>>>>>        *
>>>>
>>>> I'm pretty sure that it's not a good idea to attach this directly 
>>>> to the GEM object.
>>>
>>> Why do you think so? IMHO having a common way to connect mappings to 
>>> their backing buffers is a good thing, since every driver needs this 
>>> connection anyway.
>>>
>>> E.g. when a BO gets evicted, drivers can just iterate the list of 
>>> mappings and, as the circumstances require, invalidate the 
>>> corresponding mappings or to unmap all existing mappings of a given 
>>> buffer.
>>>
>>> What would be the advantage to let every driver implement a driver 
>>> specific way of keeping this connection?
>>
>> Flexibility. For example on amdgpu the mappings of a BO are groups by 
>> VM address spaces.
>>
>> E.g. the BO points to multiple bo_vm structures which in turn have 
>> lists of their mappings.
>
> Isn't this (almost) the same relationship I introduce with the GPUVA 
> manager?
>
> If you would switch over to the GPUVA manager right now, it would be 
> that every GEM has a list of it's mappings (the gpuva list). The 
> mapping is represented by struct drm_gpuva (of course embedded in 
> driver specific structure(s)) which has a pointer to the VM address 
> space it is part of, namely the GPUVA manager instance. And the GPUVA 
> manager keeps a maple tree of it's mappings as well.
>
> If you still would like to *directly* (indirectly you already have 
> that relationship) keep a list of GPUVA managers (VM address spaces) 
> per GEM, you could still do that in a driver specific way.
>
> Do I miss something?

How do you efficiently find only the mappings of a BO in one VM?

Keep in mind that we have cases where one BO is shared with hundreds of 
different VMs as well as potentially the number of mappings can be >10k.

>
>>
>> Additional to that there is a state maschine associated with the 
>> mappings, e.g. if the page tables are up to date or need to be 
>> updated etc....
>>
>>> Do you see cases where this kind of connection between mappings and 
>>> backing buffers wouldn't be good enough? If so, which cases do you 
>>> have in mind? Maybe we can cover them in a common way as well?
>>
>> Yeah, we have tons of cases like that. But I have no idea how to 
>> generalize them.
>
> They could still remain to be driver specific then, right?

Well does the mapping has a back pointer to the BO? And can that be 
optional NULL if there is no BO?

Regards,
Christian.

>
>>
>>>
>>>>
>>>> As you wrote in the commit message it's highly driver specific what 
>>>> to map and where to map it.
>>>
>>> In the end the common case should be that in a VA space at least 
>>> every mapping being backed by a BO is represented by a struct 
>>> drm_gpuva.
>>
>> Oh, no! We also have mappings not backed by a BO at all! For example 
>> for partial resident textures or data routing to internal hw etc...
>>
>> You can't be sure that a mapping is backed by a BO at all.
>
> I fully agree, that's why I wrote "the common case should be that in a 
> VA space at least every mapping *being backed by a BO* is represented 
> by a struct drm_gpuva".
>
> Mappings not being backed by an actual BO would not be linked to a GEM 
> of course.
>
>>
>>>
>>>>
>>>> Instead I suggest to have a separate structure for mappings in a VA 
>>>> space which driver can then add to their GEM objects or whatever 
>>>> they want to map into their VMs.
>>>
>>> Which kind of separate structure for mappings? Another one analogous 
>>> to struct drm_gpuva?
>>
>> Well similar to what amdgpu uses BO -> one structure for each 
>> combination of BO and VM -> mappings inside that VM
>
> As explained above, I think that's exactly what the GPUVA manager 
> does, just in another order:
>
> BO has list of mappings, mappings have pointer to VM, VM has list (or 
> actually a maple tree) of mappings.
>
> You see any advantages or disadvantages of either order of 
> relationships? For me it looks like it doesn't really matter which one 
> to pick.
>
> - Danilo
>
>>
>> Regards,
>> Christian.
>>
>>>
>>> - Danilo
>>>
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>
>>>
>>
>
Danilo Krummrich June 22, 2023, 3:04 p.m. UTC | #10
On 6/22/23 16:42, Christian König wrote:
> Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
>> On 6/22/23 15:54, Christian König wrote:
>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
>>>> Hi Christian,
>>>>
>>>> On 6/20/23 08:45, Christian König wrote:
>>>>> Hi Danilo,
>>>>>
>>>>> sorry for the delayed reply. I've trying to dig myself out of a 
>>>>> hole at the moment.
>>>>
>>>> No worries, thank you for taking a look anyway!
>>>>
>>>>>
>>>>> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>>>>>> [SNIP]
>>>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>>>> index bbc721870c13..5ec8148a30ee 100644
>>>>>> --- a/include/drm/drm_gem.h
>>>>>> +++ b/include/drm/drm_gem.h
>>>>>> @@ -36,6 +36,8 @@
>>>>>>   #include <linux/kref.h>
>>>>>>   #include <linux/dma-resv.h>
>>>>>> +#include <linux/list.h>
>>>>>> +#include <linux/mutex.h>
>>>>>>   #include <drm/drm_vma_manager.h>
>>>>>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>>>>>        */
>>>>>>       struct dma_resv _resv;
>>>>>> +    /**
>>>>>> +     * @gpuva:
>>>>>> +     *
>>>>>> +     * Provides the list of GPU VAs attached to this GEM object.
>>>>>> +     *
>>>>>> +     * Drivers should lock list accesses with the GEMs &dma_resv 
>>>>>> lock
>>>>>> +     * (&drm_gem_object.resv).
>>>>>> +     */
>>>>>> +    struct {
>>>>>> +        struct list_head list;
>>>>>> +    } gpuva;
>>>>>> +
>>>>>>       /**
>>>>>>        * @funcs:
>>>>>>        *
>>>>>
>>>>> I'm pretty sure that it's not a good idea to attach this directly 
>>>>> to the GEM object.
>>>>
>>>> Why do you think so? IMHO having a common way to connect mappings to 
>>>> their backing buffers is a good thing, since every driver needs this 
>>>> connection anyway.
>>>>
>>>> E.g. when a BO gets evicted, drivers can just iterate the list of 
>>>> mappings and, as the circumstances require, invalidate the 
>>>> corresponding mappings or to unmap all existing mappings of a given 
>>>> buffer.
>>>>
>>>> What would be the advantage to let every driver implement a driver 
>>>> specific way of keeping this connection?
>>>
>>> Flexibility. For example on amdgpu the mappings of a BO are groups by 
>>> VM address spaces.
>>>
>>> E.g. the BO points to multiple bo_vm structures which in turn have 
>>> lists of their mappings.
>>
>> Isn't this (almost) the same relationship I introduce with the GPUVA 
>> manager?
>>
>> If you would switch over to the GPUVA manager right now, it would be 
>> that every GEM has a list of it's mappings (the gpuva list). The 
>> mapping is represented by struct drm_gpuva (of course embedded in 
>> driver specific structure(s)) which has a pointer to the VM address 
>> space it is part of, namely the GPUVA manager instance. And the GPUVA 
>> manager keeps a maple tree of it's mappings as well.
>>
>> If you still would like to *directly* (indirectly you already have 
>> that relationship) keep a list of GPUVA managers (VM address spaces) 
>> per GEM, you could still do that in a driver specific way.
>>
>> Do I miss something?
> 
> How do you efficiently find only the mappings of a BO in one VM?

Actually, I think this case should even be more efficient than with a BO 
having a list of GPUVAs (or mappings):

Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM. 
Hence, you'd only need to iterate the list of mappings for a given BO 
and check the mappings VM pointer.

Having a list of VMs per BO, you'd have to iterate the whole VM to find 
the mappings having a pointer to the given BO, right?

I'd think that a single VM potentially has more mapping entries than a 
single BO was mapped in multiple VMs.

Another case to consider is the case I originally had in mind choosing 
this relationship: finding all mappings for a given BO, which I guess 
all drivers need to do in order to invalidate mappings on BO eviction.

Having a list of VMs per BO, wouldn't you need to iterate all of the VMs 
entirely?

> 
> Keep in mind that we have cases where one BO is shared with hundreds of 
> different VMs as well as potentially the number of mappings can be >10k.
> 
>>
>>>
>>> Additional to that there is a state maschine associated with the 
>>> mappings, e.g. if the page tables are up to date or need to be 
>>> updated etc....
>>>
>>>> Do you see cases where this kind of connection between mappings and 
>>>> backing buffers wouldn't be good enough? If so, which cases do you 
>>>> have in mind? Maybe we can cover them in a common way as well?
>>>
>>> Yeah, we have tons of cases like that. But I have no idea how to 
>>> generalize them.
>>
>> They could still remain to be driver specific then, right?
> 
> Well does the mapping has a back pointer to the BO? And can that be 
> optional NULL if there is no BO?

Yes to both.

- Danilo

> 
> Regards,
> Christian.
> 
>>
>>>
>>>>
>>>>>
>>>>> As you wrote in the commit message it's highly driver specific what 
>>>>> to map and where to map it.
>>>>
>>>> In the end the common case should be that in a VA space at least 
>>>> every mapping being backed by a BO is represented by a struct 
>>>> drm_gpuva.
>>>
>>> Oh, no! We also have mappings not backed by a BO at all! For example 
>>> for partial resident textures or data routing to internal hw etc...
>>>
>>> You can't be sure that a mapping is backed by a BO at all.
>>
>> I fully agree, that's why I wrote "the common case should be that in a 
>> VA space at least every mapping *being backed by a BO* is represented 
>> by a struct drm_gpuva".
>>
>> Mappings not being backed by an actual BO would not be linked to a GEM 
>> of course.
>>
>>>
>>>>
>>>>>
>>>>> Instead I suggest to have a separate structure for mappings in a VA 
>>>>> space which driver can then add to their GEM objects or whatever 
>>>>> they want to map into their VMs.
>>>>
>>>> Which kind of separate structure for mappings? Another one analogous 
>>>> to struct drm_gpuva?
>>>
>>> Well similar to what amdgpu uses BO -> one structure for each 
>>> combination of BO and VM -> mappings inside that VM
>>
>> As explained above, I think that's exactly what the GPUVA manager 
>> does, just in another order:
>>
>> BO has list of mappings, mappings have pointer to VM, VM has list (or 
>> actually a maple tree) of mappings.
>>
>> You see any advantages or disadvantages of either order of 
>> relationships? For me it looks like it doesn't really matter which one 
>> to pick.
>>
>> - Danilo
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>>
>>>> - Danilo
>>>>
>>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>
>>>>
>>>
>>
>
Danilo Krummrich June 22, 2023, 3:07 p.m. UTC | #11
On 6/22/23 17:04, Danilo Krummrich wrote:
> On 6/22/23 16:42, Christian König wrote:
>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
>>> On 6/22/23 15:54, Christian König wrote:
>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
>>>>> Hi Christian,
>>>>>
>>>>> On 6/20/23 08:45, Christian König wrote:
>>>>>> Hi Danilo,
>>>>>>
>>>>>> sorry for the delayed reply. I've trying to dig myself out of a 
>>>>>> hole at the moment.
>>>>>
>>>>> No worries, thank you for taking a look anyway!
>>>>>
>>>>>>
>>>>>> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>>>>>>> [SNIP]
>>>>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>>>>> index bbc721870c13..5ec8148a30ee 100644
>>>>>>> --- a/include/drm/drm_gem.h
>>>>>>> +++ b/include/drm/drm_gem.h
>>>>>>> @@ -36,6 +36,8 @@
>>>>>>>   #include <linux/kref.h>
>>>>>>>   #include <linux/dma-resv.h>
>>>>>>> +#include <linux/list.h>
>>>>>>> +#include <linux/mutex.h>
>>>>>>>   #include <drm/drm_vma_manager.h>
>>>>>>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>>>>>>        */
>>>>>>>       struct dma_resv _resv;
>>>>>>> +    /**
>>>>>>> +     * @gpuva:
>>>>>>> +     *
>>>>>>> +     * Provides the list of GPU VAs attached to this GEM object.
>>>>>>> +     *
>>>>>>> +     * Drivers should lock list accesses with the GEMs &dma_resv 
>>>>>>> lock
>>>>>>> +     * (&drm_gem_object.resv).
>>>>>>> +     */
>>>>>>> +    struct {
>>>>>>> +        struct list_head list;
>>>>>>> +    } gpuva;
>>>>>>> +
>>>>>>>       /**
>>>>>>>        * @funcs:
>>>>>>>        *
>>>>>>
>>>>>> I'm pretty sure that it's not a good idea to attach this directly 
>>>>>> to the GEM object.
>>>>>
>>>>> Why do you think so? IMHO having a common way to connect mappings 
>>>>> to their backing buffers is a good thing, since every driver needs 
>>>>> this connection anyway.
>>>>>
>>>>> E.g. when a BO gets evicted, drivers can just iterate the list of 
>>>>> mappings and, as the circumstances require, invalidate the 
>>>>> corresponding mappings or to unmap all existing mappings of a given 
>>>>> buffer.
>>>>>
>>>>> What would be the advantage to let every driver implement a driver 
>>>>> specific way of keeping this connection?
>>>>
>>>> Flexibility. For example on amdgpu the mappings of a BO are groups 
>>>> by VM address spaces.
>>>>
>>>> E.g. the BO points to multiple bo_vm structures which in turn have 
>>>> lists of their mappings.
>>>
>>> Isn't this (almost) the same relationship I introduce with the GPUVA 
>>> manager?
>>>
>>> If you would switch over to the GPUVA manager right now, it would be 
>>> that every GEM has a list of it's mappings (the gpuva list). The 
>>> mapping is represented by struct drm_gpuva (of course embedded in 
>>> driver specific structure(s)) which has a pointer to the VM address 
>>> space it is part of, namely the GPUVA manager instance. And the GPUVA 
>>> manager keeps a maple tree of it's mappings as well.
>>>
>>> If you still would like to *directly* (indirectly you already have 
>>> that relationship) keep a list of GPUVA managers (VM address spaces) 
>>> per GEM, you could still do that in a driver specific way.
>>>
>>> Do I miss something?
>>
>> How do you efficiently find only the mappings of a BO in one VM?
> 
> Actually, I think this case should even be more efficient than with a BO 
> having a list of GPUVAs (or mappings):

*than with a BO having a list of VMs:

> 
> Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM. 
> Hence, you'd only need to iterate the list of mappings for a given BO 
> and check the mappings VM pointer.
> 
> Having a list of VMs per BO, you'd have to iterate the whole VM to find 
> the mappings having a pointer to the given BO, right?
> 
> I'd think that a single VM potentially has more mapping entries than a 
> single BO was mapped in multiple VMs.
> 
> Another case to consider is the case I originally had in mind choosing 
> this relationship: finding all mappings for a given BO, which I guess 
> all drivers need to do in order to invalidate mappings on BO eviction.
> 
> Having a list of VMs per BO, wouldn't you need to iterate all of the VMs 
> entirely?
> 
>>
>> Keep in mind that we have cases where one BO is shared with hundreds 
>> of different VMs as well as potentially the number of mappings can be 
>> >10k.
>>
>>>
>>>>
>>>> Additional to that there is a state maschine associated with the 
>>>> mappings, e.g. if the page tables are up to date or need to be 
>>>> updated etc....
>>>>
>>>>> Do you see cases where this kind of connection between mappings and 
>>>>> backing buffers wouldn't be good enough? If so, which cases do you 
>>>>> have in mind? Maybe we can cover them in a common way as well?
>>>>
>>>> Yeah, we have tons of cases like that. But I have no idea how to 
>>>> generalize them.
>>>
>>> They could still remain to be driver specific then, right?
>>
>> Well does the mapping has a back pointer to the BO? And can that be 
>> optional NULL if there is no BO?
> 
> Yes to both.
> 
> - Danilo
> 
>>
>> Regards,
>> Christian.
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> As you wrote in the commit message it's highly driver specific 
>>>>>> what to map and where to map it.
>>>>>
>>>>> In the end the common case should be that in a VA space at least 
>>>>> every mapping being backed by a BO is represented by a struct 
>>>>> drm_gpuva.
>>>>
>>>> Oh, no! We also have mappings not backed by a BO at all! For example 
>>>> for partial resident textures or data routing to internal hw etc...
>>>>
>>>> You can't be sure that a mapping is backed by a BO at all.
>>>
>>> I fully agree, that's why I wrote "the common case should be that in 
>>> a VA space at least every mapping *being backed by a BO* is 
>>> represented by a struct drm_gpuva".
>>>
>>> Mappings not being backed by an actual BO would not be linked to a 
>>> GEM of course.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Instead I suggest to have a separate structure for mappings in a 
>>>>>> VA space which driver can then add to their GEM objects or 
>>>>>> whatever they want to map into their VMs.
>>>>>
>>>>> Which kind of separate structure for mappings? Another one 
>>>>> analogous to struct drm_gpuva?
>>>>
>>>> Well similar to what amdgpu uses BO -> one structure for each 
>>>> combination of BO and VM -> mappings inside that VM
>>>
>>> As explained above, I think that's exactly what the GPUVA manager 
>>> does, just in another order:
>>>
>>> BO has list of mappings, mappings have pointer to VM, VM has list (or 
>>> actually a maple tree) of mappings.
>>>
>>> You see any advantages or disadvantages of either order of 
>>> relationships? For me it looks like it doesn't really matter which 
>>> one to pick.
>>>
>>> - Danilo
>>>
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>>
>>>>> - Danilo
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Christian.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Matthew Brost June 23, 2023, 2:24 a.m. UTC | #12
On Thu, Jun 22, 2023 at 05:07:11PM +0200, Danilo Krummrich wrote:
> On 6/22/23 17:04, Danilo Krummrich wrote:
> > On 6/22/23 16:42, Christian König wrote:
> > > Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
> > > > On 6/22/23 15:54, Christian König wrote:
> > > > > Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
> > > > > > Hi Christian,
> > > > > > 
> > > > > > On 6/20/23 08:45, Christian König wrote:
> > > > > > > Hi Danilo,
> > > > > > > 
> > > > > > > sorry for the delayed reply. I've trying to dig
> > > > > > > myself out of a hole at the moment.
> > > > > > 
> > > > > > No worries, thank you for taking a look anyway!
> > > > > > 
> > > > > > > 
> > > > > > > Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
> > > > > > > > [SNIP]
> > > > > > > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > > > > > > index bbc721870c13..5ec8148a30ee 100644
> > > > > > > > --- a/include/drm/drm_gem.h
> > > > > > > > +++ b/include/drm/drm_gem.h
> > > > > > > > @@ -36,6 +36,8 @@
> > > > > > > >   #include <linux/kref.h>
> > > > > > > >   #include <linux/dma-resv.h>
> > > > > > > > +#include <linux/list.h>
> > > > > > > > +#include <linux/mutex.h>
> > > > > > > >   #include <drm/drm_vma_manager.h>
> > > > > > > > @@ -379,6 +381,18 @@ struct drm_gem_object {
> > > > > > > >        */
> > > > > > > >       struct dma_resv _resv;
> > > > > > > > +    /**
> > > > > > > > +     * @gpuva:
> > > > > > > > +     *
> > > > > > > > +     * Provides the list of GPU VAs attached to this GEM object.
> > > > > > > > +     *
> > > > > > > > +     * Drivers should lock list accesses with
> > > > > > > > the GEMs &dma_resv lock
> > > > > > > > +     * (&drm_gem_object.resv).
> > > > > > > > +     */
> > > > > > > > +    struct {
> > > > > > > > +        struct list_head list;
> > > > > > > > +    } gpuva;
> > > > > > > > +
> > > > > > > >       /**
> > > > > > > >        * @funcs:
> > > > > > > >        *
> > > > > > > 
> > > > > > > I'm pretty sure that it's not a good idea to attach
> > > > > > > this directly to the GEM object.
> > > > > > 
> > > > > > Why do you think so? IMHO having a common way to connect
> > > > > > mappings to their backing buffers is a good thing, since
> > > > > > every driver needs this connection anyway.
> > > > > > 
> > > > > > E.g. when a BO gets evicted, drivers can just iterate
> > > > > > the list of mappings and, as the circumstances require,
> > > > > > invalidate the corresponding mappings or to unmap all
> > > > > > existing mappings of a given buffer.
> > > > > > 
> > > > > > What would be the advantage to let every driver
> > > > > > implement a driver specific way of keeping this
> > > > > > connection?
> > > > > 
> > > > > Flexibility. For example on amdgpu the mappings of a BO are
> > > > > groups by VM address spaces.
> > > > > 
> > > > > E.g. the BO points to multiple bo_vm structures which in
> > > > > turn have lists of their mappings.
> > > > 
> > > > Isn't this (almost) the same relationship I introduce with the
> > > > GPUVA manager?
> > > > 
> > > > If you would switch over to the GPUVA manager right now, it
> > > > would be that every GEM has a list of it's mappings (the gpuva
> > > > list). The mapping is represented by struct drm_gpuva (of course
> > > > embedded in driver specific structure(s)) which has a pointer to
> > > > the VM address space it is part of, namely the GPUVA manager
> > > > instance. And the GPUVA manager keeps a maple tree of it's
> > > > mappings as well.
> > > > 
> > > > If you still would like to *directly* (indirectly you already
> > > > have that relationship) keep a list of GPUVA managers (VM
> > > > address spaces) per GEM, you could still do that in a driver
> > > > specific way.
> > > > 
> > > > Do I miss something?
> > > 
> > > How do you efficiently find only the mappings of a BO in one VM?
> > 
> > Actually, I think this case should even be more efficient than with a BO
> > having a list of GPUVAs (or mappings):
> 
> *than with a BO having a list of VMs:
> 
> > 
> > Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM.
> > Hence, you'd only need to iterate the list of mappings for a given BO
> > and check the mappings VM pointer.
> > 
> > Having a list of VMs per BO, you'd have to iterate the whole VM to find
> > the mappings having a pointer to the given BO, right?
> > 
> > I'd think that a single VM potentially has more mapping entries than a
> > single BO was mapped in multiple VMs.
> > 
> > Another case to consider is the case I originally had in mind choosing
> > this relationship: finding all mappings for a given BO, which I guess
> > all drivers need to do in order to invalidate mappings on BO eviction.
> > 
> > Having a list of VMs per BO, wouldn't you need to iterate all of the VMs
> > entirely?
> > 

FWIW I agree with Danilo here on basically all points.

- Having GPUVA list per GEM makes a ton of sense wrt eviction and
  invalidation. Xe had this list prior to GPUVA, after GPUVA it is just
  in a common place.
- From a GPUVA to you can resolve a GEM
- GPUVA can have NULL GEM (userptr or sparse binding in Xe)
- From a VM all GPUVA can be resolved via the maple tree

This seems to do everything any reasonable driver would need.

> > > 
> > > Keep in mind that we have cases where one BO is shared with hundreds
> > > of different VMs as well as potentially the number of mappings can
> > > be >10k.
> > > 

Christian - Can you explain this use case? It seems like an odd one but
regardless the GPUVA design still works we'd just have 10k GPUVA in the
BO's list.

> > > > 
> > > > > 
> > > > > Additional to that there is a state maschine associated with
> > > > > the mappings, e.g. if the page tables are up to date or need
> > > > > to be updated etc....
> > > > > 
> > > > > > Do you see cases where this kind of connection between
> > > > > > mappings and backing buffers wouldn't be good enough? If
> > > > > > so, which cases do you have in mind? Maybe we can cover
> > > > > > them in a common way as well?
> > > > > 
> > > > > Yeah, we have tons of cases like that. But I have no idea
> > > > > how to generalize them.
> > > > 
> > > > They could still remain to be driver specific then, right?
> > > 
> > > Well does the mapping has a back pointer to the BO? And can that be
> > > optional NULL if there is no BO?
> > 
> > Yes to both.
> >

In Xe we have GPUVA with NULL BOs for userptrs and for sparse bindings.
It seems to work rather well.

Matt

> > - Danilo
> > 
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > As you wrote in the commit message it's highly
> > > > > > > driver specific what to map and where to map it.
> > > > > > 
> > > > > > In the end the common case should be that in a VA space
> > > > > > at least every mapping being backed by a BO is
> > > > > > represented by a struct drm_gpuva.
> > > > > 
> > > > > Oh, no! We also have mappings not backed by a BO at all! For
> > > > > example for partial resident textures or data routing to
> > > > > internal hw etc...
> > > > > 
> > > > > You can't be sure that a mapping is backed by a BO at all.
> > > > 
> > > > I fully agree, that's why I wrote "the common case should be
> > > > that in a VA space at least every mapping *being backed by a BO*
> > > > is represented by a struct drm_gpuva".
> > > > 
> > > > Mappings not being backed by an actual BO would not be linked to
> > > > a GEM of course.
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Instead I suggest to have a separate structure for
> > > > > > > mappings in a VA space which driver can then add to
> > > > > > > their GEM objects or whatever they want to map into
> > > > > > > their VMs.
> > > > > > 
> > > > > > Which kind of separate structure for mappings? Another
> > > > > > one analogous to struct drm_gpuva?
> > > > > 
> > > > > Well similar to what amdgpu uses BO -> one structure for
> > > > > each combination of BO and VM -> mappings inside that VM
> > > > 
> > > > As explained above, I think that's exactly what the GPUVA
> > > > manager does, just in another order:
> > > > 
> > > > BO has list of mappings, mappings have pointer to VM, VM has
> > > > list (or actually a maple tree) of mappings.
> > > > 
> > > > You see any advantages or disadvantages of either order of
> > > > relationships? For me it looks like it doesn't really matter
> > > > which one to pick.
> > > > 
> > > > - Danilo
> > > > 
> > > > > 
> > > > > Regards,
> > > > > Christian.
> > > > > 
> > > > > > 
> > > > > > - Danilo
> > > > > > 
> > > > > > > 
> > > > > > > Regards,
> > > > > > > Christian.
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
>
Christian König June 23, 2023, 7:16 a.m. UTC | #13
Am 22.06.23 um 17:07 schrieb Danilo Krummrich:
> On 6/22/23 17:04, Danilo Krummrich wrote:
>> On 6/22/23 16:42, Christian König wrote:
>>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
>>>> On 6/22/23 15:54, Christian König wrote:
>>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
>>>>>> Hi Christian,
>>>>>>
>>>>>> On 6/20/23 08:45, Christian König wrote:
>>>>>>> Hi Danilo,
>>>>>>>
>>>>>>> sorry for the delayed reply. I've trying to dig myself out of a 
>>>>>>> hole at the moment.
>>>>>>
>>>>>> No worries, thank you for taking a look anyway!
>>>>>>
>>>>>>>
>>>>>>> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>>>>>>>> [SNIP]
>>>>>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>>>>>> index bbc721870c13..5ec8148a30ee 100644
>>>>>>>> --- a/include/drm/drm_gem.h
>>>>>>>> +++ b/include/drm/drm_gem.h
>>>>>>>> @@ -36,6 +36,8 @@
>>>>>>>>   #include <linux/kref.h>
>>>>>>>>   #include <linux/dma-resv.h>
>>>>>>>> +#include <linux/list.h>
>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>   #include <drm/drm_vma_manager.h>
>>>>>>>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>>>>>>>        */
>>>>>>>>       struct dma_resv _resv;
>>>>>>>> +    /**
>>>>>>>> +     * @gpuva:
>>>>>>>> +     *
>>>>>>>> +     * Provides the list of GPU VAs attached to this GEM object.
>>>>>>>> +     *
>>>>>>>> +     * Drivers should lock list accesses with the GEMs 
>>>>>>>> &dma_resv lock
>>>>>>>> +     * (&drm_gem_object.resv).
>>>>>>>> +     */
>>>>>>>> +    struct {
>>>>>>>> +        struct list_head list;
>>>>>>>> +    } gpuva;
>>>>>>>> +
>>>>>>>>       /**
>>>>>>>>        * @funcs:
>>>>>>>>        *
>>>>>>>
>>>>>>> I'm pretty sure that it's not a good idea to attach this 
>>>>>>> directly to the GEM object.
>>>>>>
>>>>>> Why do you think so? IMHO having a common way to connect mappings 
>>>>>> to their backing buffers is a good thing, since every driver 
>>>>>> needs this connection anyway.
>>>>>>
>>>>>> E.g. when a BO gets evicted, drivers can just iterate the list of 
>>>>>> mappings and, as the circumstances require, invalidate the 
>>>>>> corresponding mappings or to unmap all existing mappings of a 
>>>>>> given buffer.
>>>>>>
>>>>>> What would be the advantage to let every driver implement a 
>>>>>> driver specific way of keeping this connection?
>>>>>
>>>>> Flexibility. For example on amdgpu the mappings of a BO are groups 
>>>>> by VM address spaces.
>>>>>
>>>>> E.g. the BO points to multiple bo_vm structures which in turn have 
>>>>> lists of their mappings.
>>>>
>>>> Isn't this (almost) the same relationship I introduce with the 
>>>> GPUVA manager?
>>>>
>>>> If you would switch over to the GPUVA manager right now, it would 
>>>> be that every GEM has a list of it's mappings (the gpuva list). The 
>>>> mapping is represented by struct drm_gpuva (of course embedded in 
>>>> driver specific structure(s)) which has a pointer to the VM address 
>>>> space it is part of, namely the GPUVA manager instance. And the 
>>>> GPUVA manager keeps a maple tree of it's mappings as well.
>>>>
>>>> If you still would like to *directly* (indirectly you already have 
>>>> that relationship) keep a list of GPUVA managers (VM address 
>>>> spaces) per GEM, you could still do that in a driver specific way.
>>>>
>>>> Do I miss something?
>>>
>>> How do you efficiently find only the mappings of a BO in one VM?
>>
>> Actually, I think this case should even be more efficient than with a 
>> BO having a list of GPUVAs (or mappings):
>
> *than with a BO having a list of VMs:
>
>>
>> Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM. 
>> Hence, you'd only need to iterate the list of mappings for a given BO 
>> and check the mappings VM pointer.

Yeah, and that is extremely time consuming if you have tons of mappings 
in different VMs.

>>
>> Having a list of VMs per BO, you'd have to iterate the whole VM to 
>> find the mappings having a pointer to the given BO, right?

No, you don't seem to understand what I'm suggesting.

Currently you have a list of mappings attached to the BO, so when you 
need to make sure that a specific BO is up to date in a specific VM you 
either need to iterate over the VM or the BO. Neither of that is a good 
idea.

What you need is a representation of the data used for each BO+VM 
combination. In other words another indirection which allows you to 
handle all the mappings of a BO inside a VM at once.

>>
>> I'd think that a single VM potentially has more mapping entries than 
>> a single BO was mapped in multiple VMs.
>>
>> Another case to consider is the case I originally had in mind 
>> choosing this relationship: finding all mappings for a given BO, 
>> which I guess all drivers need to do in order to invalidate mappings 
>> on BO eviction.
>>
>> Having a list of VMs per BO, wouldn't you need to iterate all of the 
>> VMs entirely?

No, see how amdgpu works.

Regards,
Christian.
Danilo Krummrich June 23, 2023, 1:55 p.m. UTC | #14
On 6/23/23 09:16, Christian König wrote:
> Am 22.06.23 um 17:07 schrieb Danilo Krummrich:
>> On 6/22/23 17:04, Danilo Krummrich wrote:
>>> On 6/22/23 16:42, Christian König wrote:
>>>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
>>>>> On 6/22/23 15:54, Christian König wrote:
>>>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>> On 6/20/23 08:45, Christian König wrote:
>>>>>>>> Hi Danilo,
>>>>>>>>
>>>>>>>> sorry for the delayed reply. I've trying to dig myself out of a 
>>>>>>>> hole at the moment.
>>>>>>>
>>>>>>> No worries, thank you for taking a look anyway!
>>>>>>>
>>>>>>>>
>>>>>>>> Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
>>>>>>>>> [SNIP]
>>>>>>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>>>>>>> index bbc721870c13..5ec8148a30ee 100644
>>>>>>>>> --- a/include/drm/drm_gem.h
>>>>>>>>> +++ b/include/drm/drm_gem.h
>>>>>>>>> @@ -36,6 +36,8 @@
>>>>>>>>>   #include <linux/kref.h>
>>>>>>>>>   #include <linux/dma-resv.h>
>>>>>>>>> +#include <linux/list.h>
>>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>>   #include <drm/drm_vma_manager.h>
>>>>>>>>> @@ -379,6 +381,18 @@ struct drm_gem_object {
>>>>>>>>>        */
>>>>>>>>>       struct dma_resv _resv;
>>>>>>>>> +    /**
>>>>>>>>> +     * @gpuva:
>>>>>>>>> +     *
>>>>>>>>> +     * Provides the list of GPU VAs attached to this GEM object.
>>>>>>>>> +     *
>>>>>>>>> +     * Drivers should lock list accesses with the GEMs 
>>>>>>>>> &dma_resv lock
>>>>>>>>> +     * (&drm_gem_object.resv).
>>>>>>>>> +     */
>>>>>>>>> +    struct {
>>>>>>>>> +        struct list_head list;
>>>>>>>>> +    } gpuva;
>>>>>>>>> +
>>>>>>>>>       /**
>>>>>>>>>        * @funcs:
>>>>>>>>>        *
>>>>>>>>
>>>>>>>> I'm pretty sure that it's not a good idea to attach this 
>>>>>>>> directly to the GEM object.
>>>>>>>
>>>>>>> Why do you think so? IMHO having a common way to connect mappings 
>>>>>>> to their backing buffers is a good thing, since every driver 
>>>>>>> needs this connection anyway.
>>>>>>>
>>>>>>> E.g. when a BO gets evicted, drivers can just iterate the list of 
>>>>>>> mappings and, as the circumstances require, invalidate the 
>>>>>>> corresponding mappings or to unmap all existing mappings of a 
>>>>>>> given buffer.
>>>>>>>
>>>>>>> What would be the advantage to let every driver implement a 
>>>>>>> driver specific way of keeping this connection?
>>>>>>
>>>>>> Flexibility. For example on amdgpu the mappings of a BO are groups 
>>>>>> by VM address spaces.
>>>>>>
>>>>>> E.g. the BO points to multiple bo_vm structures which in turn have 
>>>>>> lists of their mappings.
>>>>>
>>>>> Isn't this (almost) the same relationship I introduce with the 
>>>>> GPUVA manager?
>>>>>
>>>>> If you would switch over to the GPUVA manager right now, it would 
>>>>> be that every GEM has a list of it's mappings (the gpuva list). The 
>>>>> mapping is represented by struct drm_gpuva (of course embedded in 
>>>>> driver specific structure(s)) which has a pointer to the VM address 
>>>>> space it is part of, namely the GPUVA manager instance. And the 
>>>>> GPUVA manager keeps a maple tree of it's mappings as well.
>>>>>
>>>>> If you still would like to *directly* (indirectly you already have 
>>>>> that relationship) keep a list of GPUVA managers (VM address 
>>>>> spaces) per GEM, you could still do that in a driver specific way.
>>>>>
>>>>> Do I miss something?
>>>>
>>>> How do you efficiently find only the mappings of a BO in one VM?
>>>
>>> Actually, I think this case should even be more efficient than with a 
>>> BO having a list of GPUVAs (or mappings):
>>
>> *than with a BO having a list of VMs:
>>
>>>
>>> Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's VM. 
>>> Hence, you'd only need to iterate the list of mappings for a given BO 
>>> and check the mappings VM pointer.
> 
> Yeah, and that is extremely time consuming if you have tons of mappings 
> in different VMs.
> 
>>>
>>> Having a list of VMs per BO, you'd have to iterate the whole VM to 
>>> find the mappings having a pointer to the given BO, right?
> 
> No, you don't seem to understand what I'm suggesting.
> 
> Currently you have a list of mappings attached to the BO, so when you 
> need to make sure that a specific BO is up to date in a specific VM you 
> either need to iterate over the VM or the BO. Neither of that is a good 
> idea.
> 
> What you need is a representation of the data used for each BO+VM 
> combination. In other words another indirection which allows you to 
> handle all the mappings of a BO inside a VM at once.

Ok, after having a quick look at amdgpu, I can see what you mean.

The missing piece for me was that the BO+VM abstraction itself keeps a 
list of mappings for this specific BO and VM.

Just to make it obvious for other people following the discussion, let 
me quickly sketch up how this approach would look like for the GPUVA 
manager:

1. We would need a new structure to represent the BO+VM combination, 
something like:

	struct drm_gpuva_mgr_gem {
     		struct drm_gpuva_manager *mgr;
		struct drm_gem_object *obj;
		struct list_head gpuva_list;
	};

with a less horrible name, hopefully.

2. Create an instance of struct drm_gpuva_mgr_gem once a GEM becomes 
associated with a GPUVA manager (VM) and attach it to the GEMs, as by 
now, "gpuva" list.

In amdgpu, for example, this seems to be the case once a GEM object is 
opened, since there is one VM per file_priv.

However, for other drivers this could be different, hence drivers would 
need to take care about this.


3. Attach GPUVAs to the new gpuva_list of the corresponding instance of
struct drm_gpuva_mgr_gem.

4. Drivers would need to clean up the instance of struct 
drm_gpuva_mgr_gem, once the GEM is not associated with the GPUVA manager 
anymore.

As pointed out by Christian, this would optimize the "get all mappings 
backed by a specific BO from a given VM" use case.

The question for me is, do other drivers than amdgpu commonly need this?

And what does amdgpu need this for? Maybe amdgpu does something we're 
not doing (yet)?

Christian - I know you didn't ask for "do it the way amdgpu does", 
instead you voted for keeping it entirely driver specific. But I think 
everyone is pretty close and I'm still optimistic that we could just 
generalize this.

- Danilo

> 
>>>
>>> I'd think that a single VM potentially has more mapping entries than 
>>> a single BO was mapped in multiple VMs.
>>>
>>> Another case to consider is the case I originally had in mind 
>>> choosing this relationship: finding all mappings for a given BO, 
>>> which I guess all drivers need to do in order to invalidate mappings 
>>> on BO eviction.
>>>
>>> Having a list of VMs per BO, wouldn't you need to iterate all of the 
>>> VMs entirely?
> 
> No, see how amdgpu works.
> 
> Regards,
> Christian.
>
Christian König June 23, 2023, 3:34 p.m. UTC | #15
Am 23.06.23 um 15:55 schrieb Danilo Krummrich:
> [SNIP]
>>>>> How do you efficiently find only the mappings of a BO in one VM?
>>>>
>>>> Actually, I think this case should even be more efficient than with 
>>>> a BO having a list of GPUVAs (or mappings):
>>>
>>> *than with a BO having a list of VMs:
>>>
>>>>
>>>> Having a list of GPUVAs per GEM, each GPUVA has a pointer to it's 
>>>> VM. Hence, you'd only need to iterate the list of mappings for a 
>>>> given BO and check the mappings VM pointer.
>>
>> Yeah, and that is extremely time consuming if you have tons of 
>> mappings in different VMs.
>>
>>>>
>>>> Having a list of VMs per BO, you'd have to iterate the whole VM to 
>>>> find the mappings having a pointer to the given BO, right?
>>
>> No, you don't seem to understand what I'm suggesting.
>>
>> Currently you have a list of mappings attached to the BO, so when you 
>> need to make sure that a specific BO is up to date in a specific VM 
>> you either need to iterate over the VM or the BO. Neither of that is 
>> a good idea.
>>
>> What you need is a representation of the data used for each BO+VM 
>> combination. In other words another indirection which allows you to 
>> handle all the mappings of a BO inside a VM at once.
>
> Ok, after having a quick look at amdgpu, I can see what you mean.
>
> The missing piece for me was that the BO+VM abstraction itself keeps a 
> list of mappings for this specific BO and VM.
>
> Just to make it obvious for other people following the discussion, let 
> me quickly sketch up how this approach would look like for the GPUVA 
> manager:
>
> 1. We would need a new structure to represent the BO+VM combination, 
> something like:
>
>     struct drm_gpuva_mgr_gem {
>             struct drm_gpuva_manager *mgr;
>         struct drm_gem_object *obj;
>         struct list_head gpuva_list;
>     };
>
> with a less horrible name, hopefully.
>
> 2. Create an instance of struct drm_gpuva_mgr_gem once a GEM becomes 
> associated with a GPUVA manager (VM) and attach it to the GEMs, as by 
> now, "gpuva" list.
>
> In amdgpu, for example, this seems to be the case once a GEM object is 
> opened, since there is one VM per file_priv.
>
> However, for other drivers this could be different, hence drivers 
> would need to take care about this.

Yes, exactly that.

>
>
> 3. Attach GPUVAs to the new gpuva_list of the corresponding instance of
> struct drm_gpuva_mgr_gem.
>
> 4. Drivers would need to clean up the instance of struct 
> drm_gpuva_mgr_gem, once the GEM is not associated with the GPUVA 
> manager anymore.
>
> As pointed out by Christian, this would optimize the "get all mappings 
> backed by a specific BO from a given VM" use case.
>
> The question for me is, do other drivers than amdgpu commonly need this?

I have no idea.

>
> And what does amdgpu need this for? Maybe amdgpu does something we're 
> not doing (yet)?

Basically when we do a CS we need to make sure that the VM used by this 
CS is up to date. For this we walk over the relocation list of BOs and 
check the status of each BO+VM structure.

This is done because we don't want to update all VMs at the same time, 
but rather just those who needs the update.

>
> Christian - I know you didn't ask for "do it the way amdgpu does", 
> instead you voted for keeping it entirely driver specific. But I think 
> everyone is pretty close and I'm still optimistic that we could just 
> generalize this.

Well, you should *not* necessarily do it like amdgpu does! Basically the 
implementation in amdgpu was driven by requirements, e.g. we need that, 
let's do it like this.

It's perfectly possible that other requirements (e.g. focus on Vulkan) 
lead to a completely different implementation.

It's just that ideally I would like to have an implementation where I 
can apply at least the basics to amdgpu as well.

Regards,
Christian.

>
> - Danilo
>
>>
>>>>
>>>> I'd think that a single VM potentially has more mapping entries 
>>>> than a single BO was mapped in multiple VMs.
>>>>
>>>> Another case to consider is the case I originally had in mind 
>>>> choosing this relationship: finding all mappings for a given BO, 
>>>> which I guess all drivers need to do in order to invalidate 
>>>> mappings on BO eviction.
>>>>
>>>> Having a list of VMs per BO, wouldn't you need to iterate all of 
>>>> the VMs entirely?
>>
>> No, see how amdgpu works.
>>
>> Regards,
>> Christian.
>>
>
Dave Airlie June 26, 2023, 10:38 p.m. UTC | #16
> > As pointed out by Christian, this would optimize the "get all mappings
> > backed by a specific BO from a given VM" use case.
> >
> > The question for me is, do other drivers than amdgpu commonly need this?
>
> I have no idea.
>
> >
> > And what does amdgpu need this for? Maybe amdgpu does something we're
> > not doing (yet)?
>
> Basically when we do a CS we need to make sure that the VM used by this
> CS is up to date. For this we walk over the relocation list of BOs and
> check the status of each BO+VM structure.
>
> This is done because we don't want to update all VMs at the same time,
> but rather just those who needs the update.

This seems like a legacy from GL and possibly older vulkan, going
forward vulkan can't rely on passing lists of objects into the kernel
due to things like buffer_device_address, I'm not sure we should
optimise for this situation, and moving the tracking list into the
drivers is going to mean having a bunch of drivers all having the same
boilerplate, to do the same thing just so amdgpu can't avoid doing it.

Now there might be some benchmark somewhere we can produce a benefit
in this, and if there is then we should consider going this way for
all drivers and not just allowing drivers to choose their own path
here.

> >
> > Christian - I know you didn't ask for "do it the way amdgpu does",
> > instead you voted for keeping it entirely driver specific. But I think
> > everyone is pretty close and I'm still optimistic that we could just
> > generalize this.
>
> Well, you should *not* necessarily do it like amdgpu does! Basically the
> implementation in amdgpu was driven by requirements, e.g. we need that,
> let's do it like this.
>
> It's perfectly possible that other requirements (e.g. focus on Vulkan)
> lead to a completely different implementation.
>
> It's just that ideally I would like to have an implementation where I
> can apply at least the basics to amdgpu as well.
>

I think we can still do that just either have an option to disable
using the list internally in the gpuva or have the driver keep it's
own tracking alongside, there may still be use cases where it can use
the gpuva tracking instead of it's own.

I don't think we should forklift what is pretty likely to be common
code across every driver that uses this going forward just to benefit
an amdgpu design decision for older stacks.

Dave.
diff mbox series

Patch

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a52e6f4117d6..0a9d54e723a8 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -466,6 +466,48 @@  DRM MM Range Allocator Function References
 .. kernel-doc:: drivers/gpu/drm/drm_mm.c
    :export:
 
+DRM GPU VA Manager
+==================
+
+Overview
+--------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Overview
+
+Split and Merge
+---------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Split and Merge
+
+Locking
+-------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Locking
+
+Examples
+--------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Examples
+
+Quirks
+------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Quirks
+
+DRM GPU VA Manager Function References
+--------------------------------------
+
+.. kernel-doc:: include/drm/drm_gpuva_mgr.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :export:
+
 DRM Buddy Allocator
 ===================
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 414855e2a463..6d6c9dec66e8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -45,6 +45,7 @@  drm-y := \
 	drm_vblank.o \
 	drm_vblank_work.o \
 	drm_vma_manager.o \
+	drm_gpuva_mgr.o \
 	drm_writeback.o
 drm-$(CONFIG_DRM_LEGACY) += \
 	drm_agpsupport.o \
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1a5a2cd0d4ec..cd878ebddbd0 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -164,6 +164,9 @@  void drm_gem_private_object_init(struct drm_device *dev,
 	if (!obj->resv)
 		obj->resv = &obj->_resv;
 
+	if (drm_core_check_feature(dev, DRIVER_GEM_GPUVA))
+		drm_gem_gpuva_init(obj);
+
 	drm_vma_node_reset(&obj->vma_node);
 	INIT_LIST_HEAD(&obj->lru_node);
 }
diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c
new file mode 100644
index 000000000000..66989db49cae
--- /dev/null
+++ b/drivers/gpu/drm/drm_gpuva_mgr.c
@@ -0,0 +1,1971 @@ 
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * 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_gem.h>
+#include <drm/drm_gpuva_mgr.h>
+
+/**
+ * DOC: Overview
+ *
+ * The DRM GPU VA Manager, represented by struct drm_gpuva_manager 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 &maple_tree to manage the
+ * &drm_gpuva mappings within a GPU's virtual address space.
+ *
+ * The &drm_gpuva_manager 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_gpuva_manager and
+ * struct drm_gpuva within their own driver specific structures, there won't be
+ * any memory allocations of it's own nor memory allocations of &drm_gpuva
+ * entries.
+ *
+ * However, the &drm_gpuva_manager needs to allocate nodes for it's internal
+ * tree structures when &drm_gpuva entries are inserted. In order to support
+ * inserting &drm_gpuva entries from dma-fence signalling critical sections the
+ * &drm_gpuva_manager provides struct drm_gpuva_prealloc. Drivers may create
+ * pre-allocated nodes which drm_gpuva_prealloc_create() and subsequently insert
+ * a new &drm_gpuva entry with drm_gpuva_insert_prealloc().
+ */
+
+/**
+ * DOC: Split and Merge
+ *
+ * Besides it's capability to manage and represent a GPU VA space, the
+ * &drm_gpuva_manager also provides functions to let the &drm_gpuva_manager
+ * 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_gpuva_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_gpuva_fn_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_gpuva_manager'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_gpuva_sm_map() drm_gpuva_sm_unmap() uses &drm_gpuva_fn_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_gpuva_sm_map() and drm_gpuva_sm_unmap(),
+ * drm_gpuva_sm_map_ops_create() and drm_gpuva_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_gpuva_sm_map() or drm_gpuva_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_gpuva_manager's view of the GPU VA space
+ * drm_gpuva_insert(), drm_gpuva_insert_prealloc(), and drm_gpuva_remove() may
+ * be used. Please note that these functions are not safe to be called from a
+ * &drm_gpuva_fn_ops callback originating from drm_gpuva_sm_map() or
+ * drm_gpuva_sm_unmap(). The drm_gpuva_map(), drm_gpuva_remap() and
+ * drm_gpuva_unmap() helpers should be used 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_gpuva_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 it's 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 it's 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 the GEMs dma_resv lock.
+ */
+
+/**
+ * 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 and prepares it's fields.
+ *	struct drm_gpuva * driver_create_gpuva(struct drm_gpuva_op_map *op);
+ *
+ *	// Typically drivers would embedd the &drm_gpuva_manager 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_gpuva_manager *mgr,
+ *				  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_gpuva_sm_map_ops_create(mgr, 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_create_gpuva(&op->map);
+ *				if (!va)
+ *					; // unwind previous VA space updates,
+ *					     free memory and unlock
+ *
+ *				driver_vm_map();
+ *				drm_gpuva_insert(va);
+ *				drm_gpuva_link(va);
+ *				break;
+ *			case DRM_GPUVA_OP_REMAP:
+ *				va = op->remap.unmap->va;
+ *
+ *				driver_vm_unmap();
+ *				drm_gpuva_remove(va);
+ *				dma_resv_lock(va->gem.obj->resv, NULL);
+ *				drm_gpuva_unlink(va);
+ *				dma_resv_unlock(va->gem.obj->resv);
+ *
+ *				if (op->remap.prev) {
+ *					va = driver_create_gpuva(&op->remap.prev);
+ *					if (!va)
+ *						; // unwind previous VA space updates,
+ *						     free memory and unlock
+ *
+ *					driver_vm_map();
+ *					drm_gpuva_insert(va);
+ *					dma_resv_lock(va->gem.obj->resv, NULL);
+ *					drm_gpuva_link(va);
+ *					dma_resv_unlock(va->gem.obj->resv);
+ *				}
+ *
+ *				if (op->remap.next) {
+ *					va = driver_create_gpuva(&op->remap.next);
+ *					if (!va)
+ *						; // unwind previous VA space updates,
+ *						     free memory and unlock
+ *
+ *					driver_vm_map();
+ *					drm_gpuva_insert(va);
+ *					drm_gpuva_link(va);
+ *				}
+ *
+ *				break;
+ *			case DRM_GPUVA_OP_UNMAP:
+ *				va = op->remap.unmap->va;
+ *
+ *				driver_vm_unmap();
+ *				drm_gpuva_remove(va);
+ *				drm_gpuva_unlink(va);
+ *				break;
+ *			default:
+ *				break;
+ *			}
+ *		}
+ *		driver_unlock_va_space();
+ *
+ *		return 0;
+ *	}
+ *
+ * 2) Receive a callback for each &drm_gpuva_op to create a new mapping::
+ *
+ *	// Prepares the &drm_gpuva's fields.
+ *	void driver_gpuva_init(struct drm_gpuva *va,
+ *		 	       struct drm_gpuva_op_map *op);
+ *
+ *	struct driver_context {
+ *		struct drm_gpuva_manager *mgr;
+ *		struct drm_gpuva_prealloc *pa;
+ *		struct drm_gpuva *new_va;
+ *		struct drm_gpuva *prev_va;
+ *		struct drm_gpuva *next_va;
+ *	};
+ *
+ *	// ops to pass to drm_gpuva_manager_init()
+ *	static const struct drm_gpuva_fn_ops driver_gpuva_ops = {
+ *		.sm_step_map = driver_gpuva_map,
+ *		.sm_step_remap = driver_gpuva_remap,
+ *		.sm_step_unmap = driver_gpuva_unmap,
+ *	};
+ *
+ *	// Typically drivers would embedd the &drm_gpuva_manager 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_gpuva_manager *mgr,
+ *				  u64 addr, u64 range,
+ *				  struct drm_gem_object *obj, u64 offset)
+ *	{
+ *		struct driver_context ctx;
+ *		struct drm_gpuva_ops *ops;
+ *		struct drm_gpuva_op *op;
+ *		int ret = 0;
+ *
+ *		ctx.mgr = mgr;
+ *
+ *		ctx.pa = drm_gpuva_prealloc_create(mgr);
+ *		if (!ctx.pa)
+ *			return -ENOMEM;
+ *
+ *		ctx.new_va = kzalloc(sizeof(*ctx.new_va), GFP_KERNEL);
+ *		ctx.prev_va = kzalloc(sizeof(*ctx.prev_va), GFP_KERNEL);
+ *		ctx.next_va = kzalloc(sizeof(*ctx.next_va), GFP_KERNEL);
+ *		if (!ctx.new_va || !ctx.prev_va || !ctx.next_va) {
+ *			ret = -ENOMEM;
+ *			goto out;
+ *		}
+ *
+ *		driver_lock_va_space();
+ *		ret = drm_gpuva_sm_map(mgr, &ctx, addr, range, obj, offset);
+ *		driver_unlock_va_space();
+ *
+ *	out:
+ *		kfree(ctx.new_va);
+ *		kfree(ctx.prev_va);
+ *		kfree(ctx.next_va);
+ *		drm_gpuva_prealloc_destroy(ctx.pa);
+ *		return ret;
+ *	}
+ *
+ *	int driver_gpuva_map(struct drm_gpuva_op *op, void *__ctx)
+ *	{
+ *		struct driver_context *ctx = __ctx;
+ *		int ret;
+ *
+ *		driver_gpuva_init(ctx->new_va, &op->map);
+ *
+ *		ret = drm_gpuva_map(ctx->mgr, ctx->pa, ctx->new_va);
+ *		if (ret)
+ *			return ret;
+ *
+ *		// indicate the new GPU VA was consumed
+ *		ctx->new_va = NULL;
+ *
+ *		drm_gpuva_link(ctx->new_va);
+ *
+ *		return 0;
+ *	}
+ *
+ *	int driver_gpuva_remap(struct drm_gpuva_op *op, drm_gpuva_state_t state,
+ *			       void *__ctx)
+ *	{
+ *		struct driver_context *ctx = __ctx;
+ *		struct drm_gpuva *prev = NULL, *next = NULL;
+ *		int ret;
+ *
+ *		if (op->remap.prev) {
+ *			prev = ctx->prev_va;
+ *			driver_gpuva_init(prev, op->remap.prev);
+ *		}
+ *
+ *		if (op->remap.next) {
+ *			next = ctx->next_va;
+ *			driver_gpuva_init(next, op->remap.next);
+ *		}
+ *
+ *		ret = drm_gpuva_remap(state, prev, next);
+ *		if (ret)
+ *			return ret;
+ *
+ *		drm_gpuva_unlink(op->remap.unmap->va);
+ *		kfree(op->remap.unmap->va);
+ *
+ *		if (prev) {
+ *			drm_gpuva_link(prev);
+ *			ctx->prev_va = NULL;
+ *		}
+ *
+ *		if (next) {
+ *			drm_gpuva_link(next);
+ *			ctx->next_va = NULL;
+ *		}
+ *
+ *		return 0;
+ *	}
+ *
+ *	int driver_gpuva_unmap(struct drm_gpuva_op *op, drm_gpuva_state_t state,
+ *			       void *__ctx)
+ *	{
+ *		drm_gpuva_unlink(op->unmap.va);
+ *		drm_gpuva_unmap(state);
+ *		kfree(op->unmap.va);
+ *
+ *		return 0;
+ *	}
+ */
+
+/**
+ * DOC: Quirks
+ *
+ *
+ * As mentioned above the DRM GPUVA Manager uses a maple tree to keep track
+ * of mappings internally. While this implementation generally is a great fit
+ * for the GPUVA manager it also (still) comes with a quirk to be aware of.
+ *
+ * The maple tree's index type is 'unsigned long' and hence there is no
+ * guarantee that a maple tree can always store 64-bit addresses. Currently,
+ * there is no way to pin a maple tree to 64-bit addresses, hence
+ * drm_gpuva_check_overflow() also calls out a warning if the GPUVA Manager is
+ * used for a GPU address space larger than 32-bit on a 32-bit kernel.
+ */
+
+ /*
+  * Maple Tree Locking
+  *
+  * The maple tree's advanced API requires the user of the API to protect
+  * certain tree operations with a lock (either the external or internal tree
+  * lock) for tree internal reasons.
+  *
+  * The actual rules (when to aquire/release the lock) are enforced by lockdep
+  * through the maple tree implementation.
+  *
+  * For this reason the DRM GPUVA manager takes the maple tree's internal
+  * spinlock according to the lockdep enforced rules.
+  *
+  * Please note, that this lock is *only* meant to fulfill the maple trees
+  * requirements and does not intentionally protect the DRM GPUVA manager
+  * against concurrent access.
+  *
+  * The following mail thread provides more details on why the maple tree
+  * has this requirement.
+  *
+  * https://lore.kernel.org/lkml/20230217134422.14116-5-dakr@redhat.com/
+  */
+
+#define MTREE_INDEX_TYPE typeof_member(struct ma_state, index)
+#define MTREE_INDEX_SIZE sizeof(MTREE_INDEX_TYPE)
+
+static int __drm_gpuva_insert(struct drm_gpuva_manager *mgr,
+			      struct drm_gpuva *va);
+static void __drm_gpuva_remove(struct drm_gpuva *va);
+
+static inline bool
+drm_gpuva_check_overflow(u64 addr, u64 range)
+{
+	MTREE_INDEX_TYPE end;
+
+	return WARN(check_add_overflow(addr, range, &end),
+		    "GPUVA address limited to %lu bytes, see Documentation.\n",
+		    MTREE_INDEX_SIZE);
+}
+
+static inline bool
+drm_gpuva_in_mm_range(struct drm_gpuva_manager *mgr, u64 addr, u64 range)
+{
+	u64 end = addr + range;
+	u64 mm_start = mgr->mm_start;
+	u64 mm_end = mm_start + mgr->mm_range;
+
+	return addr < mm_end && mm_start < end;
+}
+
+static inline bool
+drm_gpuva_in_kernel_node(struct drm_gpuva_manager *mgr, u64 addr, u64 range)
+{
+	u64 end = addr + range;
+	u64 kstart = mgr->kernel_alloc_node.va.addr;
+	u64 krange = mgr->kernel_alloc_node.va.range;
+	u64 kend = kstart + krange;
+
+	return krange && addr < kend && kstart < end;
+}
+
+static inline bool
+drm_gpuva_range_valid(struct drm_gpuva_manager *mgr,
+		      u64 addr, u64 range)
+{
+
+	return !drm_gpuva_check_overflow(addr, range) &&
+	       drm_gpuva_in_mm_range(mgr, addr, range) &&
+	       !drm_gpuva_in_kernel_node(mgr, addr, range);
+}
+
+/**
+ * drm_gpuva_manager_init - initialize a &drm_gpuva_manager
+ * @mgr: pointer to the &drm_gpuva_manager to initialize
+ * @name: the name of the GPU VA space
+ * @start_offset: the start offset of the GPU VA space
+ * @range: the size of the GPU VA space
+ * @reserve_offset: the start of the kernel reserved GPU VA area
+ * @reserve_range: the size of the kernel reserved GPU VA area
+ * @ops: &drm_gpuva_fn_ops called on &drm_gpuva_sm_map / &drm_gpuva_sm_unmap
+ *
+ * The &drm_gpuva_manager must be initialized with this function before use.
+ *
+ * Note that @mgr must be cleared to 0 before calling this function. The given
+ * &name is expected to be managed by the surrounding driver structures.
+ */
+void
+drm_gpuva_manager_init(struct drm_gpuva_manager *mgr,
+		       const char *name,
+		       u64 start_offset, u64 range,
+		       u64 reserve_offset, u64 reserve_range,
+		       const struct drm_gpuva_fn_ops *ops)
+{
+	mt_init(&mgr->mtree);
+
+	drm_gpuva_check_overflow(start_offset, range);
+	mgr->mm_start = start_offset;
+	mgr->mm_range = range;
+
+	mgr->name = name ? name : "unknown";
+	mgr->ops = ops;
+
+	memset(&mgr->kernel_alloc_node, 0, sizeof(struct drm_gpuva));
+
+	if (reserve_range) {
+		mgr->kernel_alloc_node.va.addr = reserve_offset;
+		mgr->kernel_alloc_node.va.range = reserve_range;
+
+		if (likely(!drm_gpuva_check_overflow(reserve_offset,
+						     reserve_range)))
+			__drm_gpuva_insert(mgr, &mgr->kernel_alloc_node);
+	}
+
+}
+EXPORT_SYMBOL(drm_gpuva_manager_init);
+
+/**
+ * drm_gpuva_manager_destroy - cleanup a &drm_gpuva_manager
+ * @mgr: pointer to the &drm_gpuva_manager to clean up
+ *
+ * Note that it is a bug to call this function on a manager that still
+ * holds GPU VA mappings.
+ */
+void
+drm_gpuva_manager_destroy(struct drm_gpuva_manager *mgr)
+{
+	mgr->name = NULL;
+
+	if (mgr->kernel_alloc_node.va.range)
+		__drm_gpuva_remove(&mgr->kernel_alloc_node);
+
+	mtree_lock(&mgr->mtree);
+	WARN(!mtree_empty(&mgr->mtree),
+	     "GPUVA tree is not empty, potentially leaking memory.");
+	__mt_destroy(&mgr->mtree);
+	mtree_unlock(&mgr->mtree);
+}
+EXPORT_SYMBOL(drm_gpuva_manager_destroy);
+
+/**
+ * drm_gpuva_iter_remove - removes the iterators current element
+ * @it: the &drm_gpuva_iterator
+ *
+ * This removes the element the iterator currently points to.
+ */
+void
+drm_gpuva_iter_remove(struct drm_gpuva_iterator *it)
+{
+	mas_lock(&it->mas);
+	mas_erase(&it->mas);
+	mas_unlock(&it->mas);
+}
+EXPORT_SYMBOL(drm_gpuva_iter_remove);
+
+/**
+ * drm_gpuva_prealloc_create - creates a preallocated node to store a
+ * &drm_gpuva entry.
+ * @mgr: the &drm_gpuva_manager to preallocate for
+ *
+ * Returns: the &drm_gpuva_prealloc object on success, NULL on failure
+ */
+struct drm_gpuva_prealloc *
+drm_gpuva_prealloc_create(struct drm_gpuva_manager *mgr)
+{
+	struct drm_gpuva_prealloc *pa;
+
+	pa = kzalloc(sizeof(*pa), GFP_KERNEL);
+	if (!pa)
+		return NULL;
+
+	mas_init(&pa->mas, &mgr->mtree, 0);
+	if (mas_preallocate(&pa->mas, GFP_KERNEL)) {
+		kfree(pa);
+		return NULL;
+	}
+
+	return pa;
+}
+EXPORT_SYMBOL(drm_gpuva_prealloc_create);
+
+/**
+ * drm_gpuva_prealloc_destroy - destroyes a preallocated node and frees the
+ * &drm_gpuva_prealloc
+ *
+ * @pa: the &drm_gpuva_prealloc to destroy
+ */
+void
+drm_gpuva_prealloc_destroy(struct drm_gpuva_prealloc *pa)
+{
+	mas_destroy(&pa->mas);
+	kfree(pa);
+}
+EXPORT_SYMBOL(drm_gpuva_prealloc_destroy);
+
+static int
+drm_gpuva_insert_state(struct drm_gpuva_manager *mgr,
+		       struct ma_state *mas,
+		       struct drm_gpuva *va)
+{
+	u64 addr = va->va.addr;
+	u64 range = va->va.range;
+	u64 last = addr + range - 1;
+
+	mas_set(mas, addr);
+
+	mas_lock(mas);
+	if (unlikely(mas_walk(mas))) {
+		mas_unlock(mas);
+		return -EEXIST;
+	}
+
+	if (unlikely(mas->last < last)) {
+		mas_unlock(mas);
+		return -EEXIST;
+	}
+
+	mas->index = addr;
+	mas->last = last;
+
+	mas_store_prealloc(mas, va);
+	mas_unlock(mas);
+
+	va->mgr = mgr;
+
+	return 0;
+}
+
+static int
+__drm_gpuva_insert(struct drm_gpuva_manager *mgr,
+		   struct drm_gpuva *va)
+{
+	MA_STATE(mas, &mgr->mtree, 0, 0);
+	int ret;
+
+	ret = mas_preallocate(&mas, GFP_KERNEL);
+	if (ret)
+		return ret;
+
+	return drm_gpuva_insert_state(mgr, &mas, va);
+}
+
+/**
+ * drm_gpuva_insert - insert a &drm_gpuva
+ * @mgr: the &drm_gpuva_manager to insert the &drm_gpuva in
+ * @va: the &drm_gpuva to insert
+ *
+ * Insert a &drm_gpuva with a given address and range into a
+ * &drm_gpuva_manager.
+ *
+ * It is not allowed to use this function while iterating this GPU VA space,
+ * e.g via drm_gpuva_iter_for_each().
+ *
+ * Returns: 0 on success, negative error code on failure.
+ */
+int
+drm_gpuva_insert(struct drm_gpuva_manager *mgr,
+		 struct drm_gpuva *va)
+{
+	u64 addr = va->va.addr;
+	u64 range = va->va.range;
+
+	if (unlikely(!drm_gpuva_range_valid(mgr, addr, range)))
+		return -EINVAL;
+
+	return __drm_gpuva_insert(mgr, va);
+}
+EXPORT_SYMBOL(drm_gpuva_insert);
+
+/**
+ * drm_gpuva_insert_prealloc - insert a &drm_gpuva with a preallocated node
+ * @mgr: the &drm_gpuva_manager to insert the &drm_gpuva in
+ * @va: the &drm_gpuva to insert
+ * @pa: the &drm_gpuva_prealloc node
+ *
+ * Insert a &drm_gpuva with a given address and range into a
+ * &drm_gpuva_manager.
+ *
+ * It is not allowed to use this function while iterating this GPU VA space,
+ * e.g via drm_gpuva_iter_for_each().
+ *
+ * Returns: 0 on success, negative error code on failure.
+ */
+int
+drm_gpuva_insert_prealloc(struct drm_gpuva_manager *mgr,
+			  struct drm_gpuva_prealloc *pa,
+			  struct drm_gpuva *va)
+{
+	struct ma_state *mas = &pa->mas;
+	u64 addr = va->va.addr;
+	u64 range = va->va.range;
+
+	if (unlikely(!drm_gpuva_range_valid(mgr, addr, range)))
+		return -EINVAL;
+
+	mas->tree = &mgr->mtree;
+	return drm_gpuva_insert_state(mgr, mas, va);
+}
+EXPORT_SYMBOL(drm_gpuva_insert_prealloc);
+
+static void
+__drm_gpuva_remove(struct drm_gpuva *va)
+{
+	MA_STATE(mas, &va->mgr->mtree, va->va.addr, 0);
+
+	mas_lock(&mas);
+	mas_erase(&mas);
+	mas_unlock(&mas);
+}
+
+/**
+ * drm_gpuva_remove - remove a &drm_gpuva
+ * @va: the &drm_gpuva to remove
+ *
+ * This removes the given &va from the underlaying tree.
+ *
+ * It is not allowed to use this function while iterating this GPU VA space,
+ * e.g via drm_gpuva_iter_for_each(). Please use drm_gpuva_iter_remove()
+ * instead.
+ */
+void
+drm_gpuva_remove(struct drm_gpuva *va)
+{
+	struct drm_gpuva_manager *mgr = va->mgr;
+
+	if (unlikely(va == &mgr->kernel_alloc_node)) {
+		WARN(1, "Can't destroy kernel reserved node.\n");
+		return;
+	}
+
+	__drm_gpuva_remove(va);
+}
+EXPORT_SYMBOL(drm_gpuva_remove);
+
+/**
+ * drm_gpuva_link - link a &drm_gpuva
+ * @va: the &drm_gpuva to link
+ *
+ * This adds the given &va to the GPU VA list of the &drm_gem_object it is
+ * associated with.
+ *
+ * This function expects the caller to protect the GEM's GPUVA list against
+ * concurrent access using the GEMs dma_resv lock.
+ */
+void
+drm_gpuva_link(struct drm_gpuva *va)
+{
+	struct drm_gem_object *obj = va->gem.obj;
+
+	if (unlikely(!obj))
+		return;
+
+	dma_resv_assert_held(obj->resv);
+	list_add_tail(&va->gem.entry, &obj->gpuva.list);
+}
+EXPORT_SYMBOL(drm_gpuva_link);
+
+/**
+ * drm_gpuva_unlink - unlink a &drm_gpuva
+ * @va: the &drm_gpuva to unlink
+ *
+ * This removes the given &va from the GPU VA list of the &drm_gem_object it is
+ * associated with.
+ *
+ * This function expects the caller to protect the GEM's GPUVA list against
+ * concurrent access using the GEMs dma_resv lock.
+ */
+void
+drm_gpuva_unlink(struct drm_gpuva *va)
+{
+	struct drm_gem_object *obj = va->gem.obj;
+
+	if (unlikely(!obj))
+		return;
+
+	dma_resv_assert_held(obj->resv);
+	list_del_init(&va->gem.entry);
+}
+EXPORT_SYMBOL(drm_gpuva_unlink);
+
+/**
+ * drm_gpuva_find_first - find the first &drm_gpuva in the given range
+ * @mgr: the &drm_gpuva_manager to search in
+ * @addr: the &drm_gpuvas address
+ * @range: the &drm_gpuvas range
+ *
+ * Returns: the first &drm_gpuva within the given range
+ */
+struct drm_gpuva *
+drm_gpuva_find_first(struct drm_gpuva_manager *mgr,
+		     u64 addr, u64 range)
+{
+	MA_STATE(mas, &mgr->mtree, addr, 0);
+	struct drm_gpuva *va;
+
+	mas_lock(&mas);
+	va = mas_find(&mas, addr + range - 1);
+	mas_unlock(&mas);
+
+	return va;
+}
+EXPORT_SYMBOL(drm_gpuva_find_first);
+
+/**
+ * drm_gpuva_find - find a &drm_gpuva
+ * @mgr: the &drm_gpuva_manager to search in
+ * @addr: the &drm_gpuvas address
+ * @range: the &drm_gpuvas range
+ *
+ * Returns: the &drm_gpuva at a given &addr and with a given &range
+ */
+struct drm_gpuva *
+drm_gpuva_find(struct drm_gpuva_manager *mgr,
+	       u64 addr, u64 range)
+{
+	struct drm_gpuva *va;
+
+	va = drm_gpuva_find_first(mgr, addr, range);
+	if (!va)
+		goto out;
+
+	if (va->va.addr != addr ||
+	    va->va.range != range)
+		goto out;
+
+	return va;
+
+out:
+	return NULL;
+}
+EXPORT_SYMBOL(drm_gpuva_find);
+
+/**
+ * drm_gpuva_find_prev - find the &drm_gpuva before the given address
+ * @mgr: the &drm_gpuva_manager to search in
+ * @start: the given GPU VA's start address
+ *
+ * Find the adjacent &drm_gpuva before the GPU VA with given &start address.
+ *
+ * Note that if there is any free space between the GPU VA mappings no mapping
+ * is returned.
+ *
+ * Returns: a pointer to the found &drm_gpuva or NULL if none was found
+ */
+struct drm_gpuva *
+drm_gpuva_find_prev(struct drm_gpuva_manager *mgr, u64 start)
+{
+	MA_STATE(mas, &mgr->mtree, start - 1, 0);
+	struct drm_gpuva *va;
+
+	if (start <= mgr->mm_start ||
+	    start > (mgr->mm_start + mgr->mm_range))
+		return NULL;
+
+	mas_lock(&mas);
+	va = mas_walk(&mas);
+	mas_unlock(&mas);
+
+	return va;
+}
+EXPORT_SYMBOL(drm_gpuva_find_prev);
+
+/**
+ * drm_gpuva_find_next - find the &drm_gpuva after the given address
+ * @mgr: the &drm_gpuva_manager to search in
+ * @end: the given GPU VA's end address
+ *
+ * Find the adjacent &drm_gpuva after the GPU VA with given &end address.
+ *
+ * Note that if there is any free space between the GPU VA mappings no mapping
+ * is returned.
+ *
+ * Returns: a pointer to the found &drm_gpuva or NULL if none was found
+ */
+struct drm_gpuva *
+drm_gpuva_find_next(struct drm_gpuva_manager *mgr, u64 end)
+{
+	MA_STATE(mas, &mgr->mtree, end, 0);
+	struct drm_gpuva *va;
+
+	if (end < mgr->mm_start ||
+	    end >= (mgr->mm_start + mgr->mm_range))
+		return NULL;
+
+	mas_lock(&mas);
+	va = mas_walk(&mas);
+	mas_unlock(&mas);
+
+	return va;
+}
+EXPORT_SYMBOL(drm_gpuva_find_next);
+
+/**
+ * drm_gpuva_interval_empty - indicate whether a given interval of the VA space
+ * is empty
+ * @mgr: the &drm_gpuva_manager to check the range for
+ * @addr: the start address of the range
+ * @range: the range of the interval
+ *
+ * Returns: true if the interval is empty, false otherwise
+ */
+bool
+drm_gpuva_interval_empty(struct drm_gpuva_manager *mgr, u64 addr, u64 range)
+{
+	DRM_GPUVA_ITER(it, mgr, addr);
+	struct drm_gpuva *va;
+
+	drm_gpuva_iter_for_each_range(va, it, addr + range)
+		return false;
+
+	return true;
+}
+EXPORT_SYMBOL(drm_gpuva_interval_empty);
+
+/**
+ * drm_gpuva_map - helper to insert a &drm_gpuva from &drm_gpuva_fn_ops
+ * callbacks
+ *
+ * @mgr: the &drm_gpuva_manager
+ * @pa: the &drm_gpuva_prealloc
+ * @va: the &drm_gpuva to inser
+ */
+int
+drm_gpuva_map(struct drm_gpuva_manager *mgr,
+	      struct drm_gpuva_prealloc *pa,
+	      struct drm_gpuva *va)
+{
+	return drm_gpuva_insert_prealloc(mgr, pa, va);
+}
+EXPORT_SYMBOL(drm_gpuva_map);
+
+/**
+ * drm_gpuva_remap - helper to insert a &drm_gpuva from &drm_gpuva_fn_ops
+ * callbacks
+ *
+ * @state: the current &drm_gpuva_state
+ * @prev: the &drm_gpuva to remap when keeping the start of a mapping,
+ * may be NULL
+ * @next: the &drm_gpuva to remap when keeping the end of a mapping,
+ * may be NULL
+ */
+int
+drm_gpuva_remap(drm_gpuva_state_t state,
+		struct drm_gpuva *prev,
+		struct drm_gpuva *next)
+{
+	struct ma_state *mas = &state->mas;
+	u64 max = mas->last;
+
+	if (unlikely(!prev && !next))
+		return -EINVAL;
+
+	if (prev) {
+		u64 addr = prev->va.addr;
+		u64 last = addr + prev->va.range - 1;
+
+		if (unlikely(addr != mas->index))
+			return -EINVAL;
+
+		if (unlikely(last >= mas->last))
+			return -EINVAL;
+	}
+
+	if (next) {
+		u64 addr = next->va.addr;
+		u64 last = addr + next->va.range - 1;
+
+		if (unlikely(last != mas->last))
+			return -EINVAL;
+
+		if (unlikely(addr <= mas->index))
+			return -EINVAL;
+	}
+
+	if (prev && next) {
+		u64 p_last = prev->va.addr + prev->va.range - 1;
+		u64 n_addr = next->va.addr;
+
+		if (unlikely(p_last > n_addr))
+			return -EINVAL;
+
+		if (unlikely(n_addr - p_last <= 1))
+			return -EINVAL;
+	}
+
+	mas_lock(mas);
+	if (prev) {
+		mas_store(mas, prev);
+		mas_next(mas, max);
+		if (!next)
+			mas_store(mas, NULL);
+	}
+
+	if (next) {
+		mas->last = next->va.addr - 1;
+		mas_store(mas, NULL);
+		mas_next(mas, max);
+		mas_store(mas, next);
+	}
+	mas_unlock(mas);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_gpuva_remap);
+
+/**
+ * drm_gpuva_unmap - helper to remove a &drm_gpuva from &drm_gpuva_fn_ops
+ * callbacks
+ *
+ * @state: the current &drm_gpuva_state
+ *
+ * The entry associated with the current state is removed.
+ */
+void
+drm_gpuva_unmap(drm_gpuva_state_t state)
+{
+	drm_gpuva_iter_remove(state);
+}
+EXPORT_SYMBOL(drm_gpuva_unmap);
+
+static int
+op_map_cb(const struct drm_gpuva_fn_ops *fn, void *priv,
+	  u64 addr, u64 range,
+	  struct drm_gem_object *obj, u64 offset)
+{
+	struct drm_gpuva_op op = {};
+
+	op.op = DRM_GPUVA_OP_MAP;
+	op.map.va.addr = addr;
+	op.map.va.range = range;
+	op.map.gem.obj = obj;
+	op.map.gem.offset = offset;
+
+	return fn->sm_step_map(&op, priv);
+}
+
+static int
+op_remap_cb(const struct drm_gpuva_fn_ops *fn,
+	    drm_gpuva_state_t state, void *priv,
+	    struct drm_gpuva_op_map *prev,
+	    struct drm_gpuva_op_map *next,
+	    struct drm_gpuva_op_unmap *unmap)
+{
+	struct drm_gpuva_op op = {};
+	struct drm_gpuva_op_remap *r;
+
+	op.op = DRM_GPUVA_OP_REMAP;
+	r = &op.remap;
+	r->prev = prev;
+	r->next = next;
+	r->unmap = unmap;
+
+	return fn->sm_step_remap(&op, state, priv);
+}
+
+static int
+op_unmap_cb(const struct drm_gpuva_fn_ops *fn,
+	    drm_gpuva_state_t state, void *priv,
+	    struct drm_gpuva *va, bool merge)
+{
+	struct drm_gpuva_op op = {};
+
+	op.op = DRM_GPUVA_OP_UNMAP;
+	op.unmap.va = va;
+	op.unmap.keep = merge;
+
+	return fn->sm_step_unmap(&op, state, priv);
+}
+
+static int
+__drm_gpuva_sm_map(struct drm_gpuva_manager *mgr,
+		   const struct drm_gpuva_fn_ops *ops, void *priv,
+		   u64 req_addr, u64 req_range,
+		   struct drm_gem_object *req_obj, u64 req_offset)
+{
+	DRM_GPUVA_ITER(it, mgr, req_addr);
+	struct drm_gpuva *va, *prev = NULL;
+	u64 req_end = req_addr + req_range;
+	int ret;
+
+	if (unlikely(!drm_gpuva_in_mm_range(mgr, req_addr, req_range)))
+		return -EINVAL;
+
+	if (unlikely(drm_gpuva_in_kernel_node(mgr, req_addr, req_range)))
+		return -EINVAL;
+
+	drm_gpuva_iter_for_each_range(va, it, req_end) {
+		struct drm_gem_object *obj = va->gem.obj;
+		u64 offset = va->gem.offset;
+		u64 addr = va->va.addr;
+		u64 range = va->va.range;
+		u64 end = addr + range;
+		bool merge = !!va->gem.obj;
+
+		if (addr == req_addr) {
+			merge &= obj == req_obj &&
+				 offset == req_offset;
+
+			if (end == req_end) {
+				ret = op_unmap_cb(ops, &it, priv, va, merge);
+				if (ret)
+					return ret;
+				break;
+			}
+
+			if (end < req_end) {
+				ret = op_unmap_cb(ops, &it, priv, va, merge);
+				if (ret)
+					return ret;
+				goto next;
+			}
+
+			if (end > req_end) {
+				struct drm_gpuva_op_map n = {
+					.va.addr = req_end,
+					.va.range = range - req_range,
+					.gem.obj = obj,
+					.gem.offset = offset + req_range,
+				};
+				struct drm_gpuva_op_unmap u = {
+					.va = va,
+					.keep = merge,
+				};
+
+				ret = op_remap_cb(ops, &it, priv, NULL, &n, &u);
+				if (ret)
+					return ret;
+				break;
+			}
+		} else if (addr < req_addr) {
+			u64 ls_range = req_addr - addr;
+			struct drm_gpuva_op_map p = {
+				.va.addr = addr,
+				.va.range = ls_range,
+				.gem.obj = obj,
+				.gem.offset = offset,
+			};
+			struct drm_gpuva_op_unmap u = { .va = va };
+
+			merge &= obj == req_obj &&
+				 offset + ls_range == req_offset;
+			u.keep = merge;
+
+			if (end == req_end) {
+				ret = op_remap_cb(ops, &it, priv, &p, NULL, &u);
+				if (ret)
+					return ret;
+				break;
+			}
+
+			if (end < req_end) {
+				ret = op_remap_cb(ops, &it, priv, &p, NULL, &u);
+				if (ret)
+					return ret;
+				goto next;
+			}
+
+			if (end > req_end) {
+				struct drm_gpuva_op_map n = {
+					.va.addr = req_end,
+					.va.range = end - req_end,
+					.gem.obj = obj,
+					.gem.offset = offset + ls_range +
+						      req_range,
+				};
+
+				ret = op_remap_cb(ops, &it, priv, &p, &n, &u);
+				if (ret)
+					return ret;
+				break;
+			}
+		} else if (addr > req_addr) {
+			merge &= obj == req_obj &&
+				 offset == req_offset +
+					   (addr - req_addr);
+
+			if (end == req_end) {
+				ret = op_unmap_cb(ops, &it, priv, va, merge);
+				if (ret)
+					return ret;
+				break;
+			}
+
+			if (end < req_end) {
+				ret = op_unmap_cb(ops, &it, priv, va, merge);
+				if (ret)
+					return ret;
+				goto next;
+			}
+
+			if (end > req_end) {
+				struct drm_gpuva_op_map n = {
+					.va.addr = req_end,
+					.va.range = end - req_end,
+					.gem.obj = obj,
+					.gem.offset = offset + req_end - addr,
+				};
+				struct drm_gpuva_op_unmap u = {
+					.va = va,
+					.keep = merge,
+				};
+
+				ret = op_remap_cb(ops, &it, priv, NULL, &n, &u);
+				if (ret)
+					return ret;
+				break;
+			}
+		}
+next:
+		prev = va;
+	}
+
+	return op_map_cb(ops, priv,
+			 req_addr, req_range,
+			 req_obj, req_offset);
+}
+
+static int
+__drm_gpuva_sm_unmap(struct drm_gpuva_manager *mgr,
+		     const struct drm_gpuva_fn_ops *ops, void *priv,
+		     u64 req_addr, u64 req_range)
+{
+	DRM_GPUVA_ITER(it, mgr, req_addr);
+	struct drm_gpuva *va;
+	u64 req_end = req_addr + req_range;
+	int ret;
+
+	if (unlikely(drm_gpuva_in_kernel_node(mgr, req_addr, req_range)))
+		return -EINVAL;
+
+	drm_gpuva_iter_for_each_range(va, it, req_end) {
+		struct drm_gpuva_op_map prev = {}, next = {};
+		bool prev_split = false, next_split = false;
+		struct drm_gem_object *obj = va->gem.obj;
+		u64 offset = va->gem.offset;
+		u64 addr = va->va.addr;
+		u64 range = va->va.range;
+		u64 end = addr + range;
+
+		if (addr < req_addr) {
+			prev.va.addr = addr;
+			prev.va.range = req_addr - addr;
+			prev.gem.obj = obj;
+			prev.gem.offset = offset;
+
+			prev_split = true;
+		}
+
+		if (end > req_end) {
+			next.va.addr = req_end;
+			next.va.range = end - req_end;
+			next.gem.obj = obj;
+			next.gem.offset = offset + (req_end - addr);
+
+			next_split = true;
+		}
+
+		if (prev_split || next_split) {
+			struct drm_gpuva_op_unmap unmap = { .va = va };
+
+			ret = op_remap_cb(ops, &it, priv,
+					  prev_split ? &prev : NULL,
+					  next_split ? &next : NULL,
+					  &unmap);
+			if (ret)
+				return ret;
+		} else {
+			ret = op_unmap_cb(ops, &it, priv, va, false);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+/**
+ * drm_gpuva_sm_map - creates the &drm_gpuva_op split/merge steps
+ * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @req_addr: the start address of the new mapping
+ * @req_range: the range of the new mapping
+ * @req_obj: the &drm_gem_object to map
+ * @req_offset: the offset within the &drm_gem_object
+ * @priv: pointer to a driver private data structure
+ *
+ * This function iterates the given range of the GPU VA space. It utilizes the
+ * &drm_gpuva_fn_ops to call back into the driver providing the split and merge
+ * steps.
+ *
+ * Drivers may use these callbacks to update the GPU VA space right away within
+ * the callback. In case the driver decides to copy and store the operations for
+ * later processing neither this function nor &drm_gpuva_sm_unmap is allowed to
+ * be called before the &drm_gpuva_manager's view of the GPU VA space was
+ * updated with the previous set of operations. To update the
+ * &drm_gpuva_manager's view of the GPU VA space drm_gpuva_insert(),
+ * drm_gpuva_destroy_locked() and/or drm_gpuva_destroy_unlocked() should be
+ * used.
+ *
+ * A sequence of callbacks can contain map, unmap and remap operations, but
+ * the sequence of callbacks might also be empty if no operation is required,
+ * e.g. if the requested mapping already exists in the exact same way.
+ *
+ * There can be an arbitrary amount of unmap operations, a maximum of two remap
+ * operations and a single map operation. The latter one represents the original
+ * map operation requested by the caller.
+ *
+ * Returns: 0 on success or a negative error code
+ */
+int
+drm_gpuva_sm_map(struct drm_gpuva_manager *mgr, void *priv,
+		 u64 req_addr, u64 req_range,
+		 struct drm_gem_object *req_obj, u64 req_offset)
+{
+	const struct drm_gpuva_fn_ops *ops = mgr->ops;
+
+	if (unlikely(!(ops && ops->sm_step_map &&
+		       ops->sm_step_remap &&
+		       ops->sm_step_unmap)))
+		return -EINVAL;
+
+	return __drm_gpuva_sm_map(mgr, ops, priv,
+				  req_addr, req_range,
+				  req_obj, req_offset);
+}
+EXPORT_SYMBOL(drm_gpuva_sm_map);
+
+/**
+ * drm_gpuva_sm_unmap - creates the &drm_gpuva_ops to split on unmap
+ * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @priv: pointer to a driver private data structure
+ * @req_addr: the start address of the range to unmap
+ * @req_range: the range of the mappings to unmap
+ *
+ * This function iterates the given range of the GPU VA space. It utilizes the
+ * &drm_gpuva_fn_ops to call back into the driver providing the operations to
+ * unmap and, if required, split existent mappings.
+ *
+ * Drivers may use these callbacks to update the GPU VA space right away within
+ * the callback. In case the driver decides to copy and store the operations for
+ * later processing neither this function nor &drm_gpuva_sm_map is allowed to be
+ * called before the &drm_gpuva_manager's view of the GPU VA space was updated
+ * with the previous set of operations. To update the &drm_gpuva_manager's view
+ * of the GPU VA space drm_gpuva_insert(), drm_gpuva_destroy_locked() and/or
+ * drm_gpuva_destroy_unlocked() should be used.
+ *
+ * A sequence of callbacks can contain unmap and remap operations, depending on
+ * whether there are actual overlapping mappings to split.
+ *
+ * There can be an arbitrary amount of unmap operations and a maximum of two
+ * remap operations.
+ *
+ * Returns: 0 on success or a negative error code
+ */
+int
+drm_gpuva_sm_unmap(struct drm_gpuva_manager *mgr, void *priv,
+		   u64 req_addr, u64 req_range)
+{
+	const struct drm_gpuva_fn_ops *ops = mgr->ops;
+
+	if (unlikely(!(ops && ops->sm_step_remap &&
+		       ops->sm_step_unmap)))
+		return -EINVAL;
+
+	return __drm_gpuva_sm_unmap(mgr, ops, priv,
+				    req_addr, req_range);
+}
+EXPORT_SYMBOL(drm_gpuva_sm_unmap);
+
+static struct drm_gpuva_op *
+gpuva_op_alloc(struct drm_gpuva_manager *mgr)
+{
+	const struct drm_gpuva_fn_ops *fn = mgr->ops;
+	struct drm_gpuva_op *op;
+
+	if (fn && fn->op_alloc)
+		op = fn->op_alloc();
+	else
+		op = kzalloc(sizeof(*op), GFP_KERNEL);
+
+	if (unlikely(!op))
+		return NULL;
+
+	return op;
+}
+
+static void
+gpuva_op_free(struct drm_gpuva_manager *mgr,
+	      struct drm_gpuva_op *op)
+{
+	const struct drm_gpuva_fn_ops *fn = mgr->ops;
+
+	if (fn && fn->op_free)
+		fn->op_free(op);
+	else
+		kfree(op);
+}
+
+static int
+drm_gpuva_sm_step(struct drm_gpuva_op *__op,
+		  drm_gpuva_state_t state,
+		  void *priv)
+{
+	struct {
+		struct drm_gpuva_manager *mgr;
+		struct drm_gpuva_ops *ops;
+	} *args = priv;
+	struct drm_gpuva_manager *mgr = args->mgr;
+	struct drm_gpuva_ops *ops = args->ops;
+	struct drm_gpuva_op *op;
+
+	op = gpuva_op_alloc(mgr);
+	if (unlikely(!op))
+		goto err;
+
+	memcpy(op, __op, sizeof(*op));
+
+	if (op->op == DRM_GPUVA_OP_REMAP) {
+		struct drm_gpuva_op_remap *__r = &__op->remap;
+		struct drm_gpuva_op_remap *r = &op->remap;
+
+		r->unmap = kmemdup(__r->unmap, sizeof(*r->unmap),
+				   GFP_KERNEL);
+		if (unlikely(!r->unmap))
+			goto err_free_op;
+
+		if (__r->prev) {
+			r->prev = kmemdup(__r->prev, sizeof(*r->prev),
+					  GFP_KERNEL);
+			if (unlikely(!r->prev))
+				goto err_free_unmap;
+		}
+
+		if (__r->next) {
+			r->next = kmemdup(__r->next, sizeof(*r->next),
+					  GFP_KERNEL);
+			if (unlikely(!r->next))
+				goto err_free_prev;
+		}
+	}
+
+	list_add_tail(&op->entry, &ops->list);
+
+	return 0;
+
+err_free_unmap:
+	kfree(op->remap.unmap);
+err_free_prev:
+	kfree(op->remap.prev);
+err_free_op:
+	gpuva_op_free(mgr, op);
+err:
+	return -ENOMEM;
+}
+
+static int
+drm_gpuva_sm_step_map(struct drm_gpuva_op *__op, void *priv)
+{
+	return drm_gpuva_sm_step(__op, NULL, priv);
+}
+
+static const struct drm_gpuva_fn_ops gpuva_list_ops = {
+	.sm_step_map = drm_gpuva_sm_step_map,
+	.sm_step_remap = drm_gpuva_sm_step,
+	.sm_step_unmap = drm_gpuva_sm_step,
+};
+
+/**
+ * drm_gpuva_sm_map_ops_create - creates the &drm_gpuva_ops to split and merge
+ * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @req_addr: the start address of the new mapping
+ * @req_range: the range of the new mapping
+ * @req_obj: the &drm_gem_object to map
+ * @req_offset: the offset within the &drm_gem_object
+ *
+ * This function creates a list of operations to perform splitting and merging
+ * of existent mapping(s) with the newly requested one.
+ *
+ * The list can be iterated with &drm_gpuva_for_each_op and must be processed
+ * in the given order. It can contain map, unmap and remap operations, but it
+ * also can be empty if no operation is required, e.g. if the requested mapping
+ * already exists is the exact same way.
+ *
+ * There can be an arbitrary amount of unmap operations, a maximum of two remap
+ * operations and a single map operation. The latter one represents the original
+ * map operation requested by the caller.
+ *
+ * Note that before calling this function again with another mapping request it
+ * is necessary to update the &drm_gpuva_manager's view of the GPU VA space. The
+ * previously obtained operations must be either processed or abandoned. To
+ * update the &drm_gpuva_manager's view of the GPU VA space drm_gpuva_insert(),
+ * drm_gpuva_destroy_locked() and/or drm_gpuva_destroy_unlocked() should be
+ * used.
+ *
+ * After the caller finished processing the returned &drm_gpuva_ops, they must
+ * be freed with &drm_gpuva_ops_free.
+ *
+ * Returns: a pointer to the &drm_gpuva_ops on success, an ERR_PTR on failure
+ */
+struct drm_gpuva_ops *
+drm_gpuva_sm_map_ops_create(struct drm_gpuva_manager *mgr,
+			    u64 req_addr, u64 req_range,
+			    struct drm_gem_object *req_obj, u64 req_offset)
+{
+	struct drm_gpuva_ops *ops;
+	struct {
+		struct drm_gpuva_manager *mgr;
+		struct drm_gpuva_ops *ops;
+	} args;
+	int ret;
+
+	ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+	if (unlikely(!ops))
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&ops->list);
+
+	args.mgr = mgr;
+	args.ops = ops;
+
+	ret = __drm_gpuva_sm_map(mgr, &gpuva_list_ops, &args,
+				 req_addr, req_range,
+				 req_obj, req_offset);
+	if (ret)
+		goto err_free_ops;
+
+	return ops;
+
+err_free_ops:
+	drm_gpuva_ops_free(mgr, ops);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(drm_gpuva_sm_map_ops_create);
+
+/**
+ * drm_gpuva_sm_unmap_ops_create - creates the &drm_gpuva_ops to split on unmap
+ * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @req_addr: the start address of the range to unmap
+ * @req_range: the range of the mappings to unmap
+ *
+ * This function creates a list of operations to perform unmapping and, if
+ * required, splitting of the mappings overlapping the unmap range.
+ *
+ * The list can be iterated with &drm_gpuva_for_each_op and must be processed
+ * in the given order. It can contain unmap and remap operations, depending on
+ * whether there are actual overlapping mappings to split.
+ *
+ * There can be an arbitrary amount of unmap operations and a maximum of two
+ * remap operations.
+ *
+ * Note that before calling this function again with another range to unmap it
+ * is necessary to update the &drm_gpuva_manager's view of the GPU VA space. The
+ * previously obtained operations must be processed or abandoned. To update the
+ * &drm_gpuva_manager's view of the GPU VA space drm_gpuva_insert(),
+ * drm_gpuva_destroy_locked() and/or drm_gpuva_destroy_unlocked() should be
+ * used.
+ *
+ * After the caller finished processing the returned &drm_gpuva_ops, they must
+ * be freed with &drm_gpuva_ops_free.
+ *
+ * Returns: a pointer to the &drm_gpuva_ops on success, an ERR_PTR on failure
+ */
+struct drm_gpuva_ops *
+drm_gpuva_sm_unmap_ops_create(struct drm_gpuva_manager *mgr,
+			      u64 req_addr, u64 req_range)
+{
+	struct drm_gpuva_ops *ops;
+	struct {
+		struct drm_gpuva_manager *mgr;
+		struct drm_gpuva_ops *ops;
+	} args;
+	int ret;
+
+	ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+	if (unlikely(!ops))
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&ops->list);
+
+	args.mgr = mgr;
+	args.ops = ops;
+
+	ret = __drm_gpuva_sm_unmap(mgr, &gpuva_list_ops, &args,
+				   req_addr, req_range);
+	if (ret)
+		goto err_free_ops;
+
+	return ops;
+
+err_free_ops:
+	drm_gpuva_ops_free(mgr, ops);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(drm_gpuva_sm_unmap_ops_create);
+
+/**
+ * drm_gpuva_prefetch_ops_create - creates the &drm_gpuva_ops to prefetch
+ * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @addr: the start address of the range to prefetch
+ * @range: the range of the mappings to prefetch
+ *
+ * This function creates a list of operations to perform prefetching.
+ *
+ * The list can be iterated with &drm_gpuva_for_each_op and must be processed
+ * in the given order. It can contain prefetch operations.
+ *
+ * There can be an arbitrary amount of prefetch operations.
+ *
+ * After the caller finished processing the returned &drm_gpuva_ops, they must
+ * be freed with &drm_gpuva_ops_free.
+ *
+ * Returns: a pointer to the &drm_gpuva_ops on success, an ERR_PTR on failure
+ */
+struct drm_gpuva_ops *
+drm_gpuva_prefetch_ops_create(struct drm_gpuva_manager *mgr,
+			      u64 addr, u64 range)
+{
+	DRM_GPUVA_ITER(it, mgr, addr);
+	struct drm_gpuva_ops *ops;
+	struct drm_gpuva_op *op;
+	struct drm_gpuva *va;
+	int ret;
+
+	ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+	if (!ops)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&ops->list);
+
+	drm_gpuva_iter_for_each_range(va, it, addr + range) {
+		op = gpuva_op_alloc(mgr);
+		if (!op) {
+			ret = -ENOMEM;
+			goto err_free_ops;
+		}
+
+		op->op = DRM_GPUVA_OP_PREFETCH;
+		op->prefetch.va = va;
+		list_add_tail(&op->entry, &ops->list);
+	}
+
+	return ops;
+
+err_free_ops:
+	drm_gpuva_ops_free(mgr, ops);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(drm_gpuva_prefetch_ops_create);
+
+/**
+ * drm_gpuva_gem_unmap_ops_create - creates the &drm_gpuva_ops to unmap a GEM
+ * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @obj: the &drm_gem_object to unmap
+ *
+ * This function creates a list of operations to perform unmapping for every
+ * GPUVA attached to a GEM.
+ *
+ * The list can be iterated with &drm_gpuva_for_each_op and consists out of an
+ * arbitrary amount of unmap operations.
+ *
+ * After the caller finished processing the returned &drm_gpuva_ops, they must
+ * be freed with &drm_gpuva_ops_free.
+ *
+ * It is the callers responsibility to protect the GEMs GPUVA list against
+ * concurrent access using the GEMs dma_resv lock.
+ *
+ * Returns: a pointer to the &drm_gpuva_ops on success, an ERR_PTR on failure
+ */
+struct drm_gpuva_ops *
+drm_gpuva_gem_unmap_ops_create(struct drm_gpuva_manager *mgr,
+			       struct drm_gem_object *obj)
+{
+	struct drm_gpuva_ops *ops;
+	struct drm_gpuva_op *op;
+	struct drm_gpuva *va;
+	int ret;
+
+	dma_resv_assert_held(obj->resv);
+
+	ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+	if (!ops)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&ops->list);
+
+	drm_gem_for_each_gpuva(va, obj) {
+		op = gpuva_op_alloc(mgr);
+		if (!op) {
+			ret = -ENOMEM;
+			goto err_free_ops;
+		}
+
+		op->op = DRM_GPUVA_OP_UNMAP;
+		op->unmap.va = va;
+		list_add_tail(&op->entry, &ops->list);
+	}
+
+	return ops;
+
+err_free_ops:
+	drm_gpuva_ops_free(mgr, ops);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(drm_gpuva_gem_unmap_ops_create);
+
+
+/**
+ * drm_gpuva_ops_free - free the given &drm_gpuva_ops
+ * @mgr: the &drm_gpuva_manager the ops were created for
+ * @ops: the &drm_gpuva_ops to free
+ *
+ * Frees the given &drm_gpuva_ops structure including all the ops associated
+ * with it.
+ */
+void
+drm_gpuva_ops_free(struct drm_gpuva_manager *mgr,
+		   struct drm_gpuva_ops *ops)
+{
+	struct drm_gpuva_op *op, *next;
+
+	drm_gpuva_for_each_op_safe(op, next, ops) {
+		list_del(&op->entry);
+
+		if (op->op == DRM_GPUVA_OP_REMAP) {
+			kfree(op->remap.prev);
+			kfree(op->remap.next);
+			kfree(op->remap.unmap);
+		}
+
+		gpuva_op_free(mgr, op);
+	}
+
+	kfree(ops);
+}
+EXPORT_SYMBOL(drm_gpuva_ops_free);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 89e2706cac56..04dbe223b1a5 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -104,6 +104,12 @@  enum drm_driver_feature {
 	 * acceleration should be handled by two drivers that are connected using auxiliary bus.
 	 */
 	DRIVER_COMPUTE_ACCEL            = BIT(7),
+	/**
+	 * @DRIVER_GEM_GPUVA:
+	 *
+	 * Driver supports user defined GPU VA bindings for GEM objects.
+	 */
+	DRIVER_GEM_GPUVA		= BIT(8),
 
 	/* IMPORTANT: Below are all the legacy flags, add new ones above. */
 
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bbc721870c13..5ec8148a30ee 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -36,6 +36,8 @@ 
 
 #include <linux/kref.h>
 #include <linux/dma-resv.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
 
 #include <drm/drm_vma_manager.h>
 
@@ -379,6 +381,18 @@  struct drm_gem_object {
 	 */
 	struct dma_resv _resv;
 
+	/**
+	 * @gpuva:
+	 *
+	 * Provides the list of GPU VAs attached to this GEM object.
+	 *
+	 * Drivers should lock list accesses with the GEMs &dma_resv lock
+	 * (&drm_gem_object.resv).
+	 */
+	struct {
+		struct list_head list;
+	} gpuva;
+
 	/**
 	 * @funcs:
 	 *
@@ -526,4 +540,42 @@  unsigned long drm_gem_lru_scan(struct drm_gem_lru *lru,
 
 int drm_gem_evict(struct drm_gem_object *obj);
 
+/**
+ * drm_gem_gpuva_init - initialize the gpuva list of a GEM object
+ * @obj: the &drm_gem_object
+ *
+ * This initializes the &drm_gem_object's &drm_gpuva list.
+ *
+ * Calling this function is only necessary for drivers intending to support the
+ * &drm_driver_feature DRIVER_GEM_GPUVA.
+ */
+static inline void drm_gem_gpuva_init(struct drm_gem_object *obj)
+{
+	INIT_LIST_HEAD(&obj->gpuva.list);
+}
+
+/**
+ * drm_gem_for_each_gpuva - iternator to walk over a list of gpuvas
+ * @entry: &drm_gpuva structure to assign to in each iteration step
+ * @obj: the &drm_gem_object the &drm_gpuvas to walk are associated with
+ *
+ * This iterator walks over all &drm_gpuva structures associated with the
+ * &drm_gpuva_manager.
+ */
+#define drm_gem_for_each_gpuva(entry__, obj__) \
+	list_for_each_entry(entry__, &(obj__)->gpuva.list, gem.entry)
+
+/**
+ * drm_gem_for_each_gpuva_safe - iternator to safely walk over a list of gpuvas
+ * @entry: &drm_gpuva structure to assign to in each iteration step
+ * @next: &next &drm_gpuva to store the next step
+ * @obj: the &drm_gem_object the &drm_gpuvas to walk are associated with
+ *
+ * This iterator walks over all &drm_gpuva structures associated with the
+ * &drm_gem_object. It is implemented with list_for_each_entry_safe(), hence
+ * it is save against removal of elements.
+ */
+#define drm_gem_for_each_gpuva_safe(entry__, next__, obj__) \
+	list_for_each_entry_safe(entry__, next__, &(obj__)->gpuva.list, gem.entry)
+
 #endif /* __DRM_GEM_H__ */
diff --git a/include/drm/drm_gpuva_mgr.h b/include/drm/drm_gpuva_mgr.h
new file mode 100644
index 000000000000..07598d40cda0
--- /dev/null
+++ b/include/drm/drm_gpuva_mgr.h
@@ -0,0 +1,682 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __DRM_GPUVA_MGR_H__
+#define __DRM_GPUVA_MGR_H__
+
+/*
+ * 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.
+ */
+
+#include <linux/maple_tree.h>
+#include <linux/mm.h>
+#include <linux/rbtree.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+struct drm_gpuva_manager;
+struct drm_gpuva_fn_ops;
+struct drm_gpuva_prealloc;
+
+/**
+ * enum drm_gpuva_flags - flags for struct drm_gpuva
+ */
+enum drm_gpuva_flags {
+	/**
+	 * @DRM_GPUVA_INVALIDATED:
+	 *
+	 * Flag indicating that the &drm_gpuva's backing GEM is invalidated.
+	 */
+	DRM_GPUVA_INVALIDATED = (1 << 0),
+
+	/**
+	 * @DRM_GPUVA_SPARSE:
+	 *
+	 * Flag indicating that the &drm_gpuva is a sparse mapping.
+	 */
+	DRM_GPUVA_SPARSE = (1 << 1),
+
+	/**
+	 * @DRM_GPUVA_USERBITS: user defined bits
+	 */
+	DRM_GPUVA_USERBITS = (1 << 2),
+};
+
+/**
+ * struct drm_gpuva - structure to track a GPU VA mapping
+ *
+ * This structure represents a GPU VA mapping and is associated with a
+ * &drm_gpuva_manager.
+ *
+ * Typically, this structure is embedded in bigger driver structures.
+ */
+struct drm_gpuva {
+	/**
+	 * @mgr: the &drm_gpuva_manager this object is associated with
+	 */
+	struct drm_gpuva_manager *mgr;
+
+	/**
+	 * @flags: the &drm_gpuva_flags for this mapping
+	 */
+	enum drm_gpuva_flags flags;
+
+	/**
+	 * @va: structure containing the address and range of the &drm_gpuva
+	 */
+	struct {
+		/**
+		 * @addr: the start address
+		 */
+		u64 addr;
+
+		/*
+		 * @range: the range
+		 */
+		u64 range;
+	} va;
+
+	/**
+	 * @gem: structure containing the &drm_gem_object and it's offset
+	 */
+	struct {
+		/**
+		 * @offset: the offset within the &drm_gem_object
+		 */
+		u64 offset;
+
+		/**
+		 * @obj: the mapped &drm_gem_object
+		 */
+		struct drm_gem_object *obj;
+
+		/**
+		 * @entry: the &list_head to attach this object to a &drm_gem_object
+		 */
+		struct list_head entry;
+	} gem;
+};
+
+void drm_gpuva_link(struct drm_gpuva *va);
+void drm_gpuva_unlink(struct drm_gpuva *va);
+
+int drm_gpuva_insert(struct drm_gpuva_manager *mgr,
+		     struct drm_gpuva *va);
+int drm_gpuva_insert_prealloc(struct drm_gpuva_manager *mgr,
+			      struct drm_gpuva_prealloc *pa,
+			      struct drm_gpuva *va);
+void drm_gpuva_remove(struct drm_gpuva *va);
+
+struct drm_gpuva *drm_gpuva_find(struct drm_gpuva_manager *mgr,
+				 u64 addr, u64 range);
+struct drm_gpuva *drm_gpuva_find_first(struct drm_gpuva_manager *mgr,
+				       u64 addr, u64 range);
+struct drm_gpuva *drm_gpuva_find_prev(struct drm_gpuva_manager *mgr, u64 start);
+struct drm_gpuva *drm_gpuva_find_next(struct drm_gpuva_manager *mgr, u64 end);
+
+bool drm_gpuva_interval_empty(struct drm_gpuva_manager *mgr, u64 addr, u64 range);
+
+/**
+ * drm_gpuva_invalidate - sets whether the backing GEM of this &drm_gpuva is
+ * invalidated
+ * @va: the &drm_gpuva to set the invalidate flag for
+ * @invalidate: indicates whether the &drm_gpuva is invalidated
+ */
+static inline void drm_gpuva_invalidate(struct drm_gpuva *va, bool invalidate)
+{
+	if (invalidate)
+		va->flags |= DRM_GPUVA_INVALIDATED;
+	else
+		va->flags &= ~DRM_GPUVA_INVALIDATED;
+}
+
+/**
+ * drm_gpuva_invalidated - indicates whether the backing BO of this &drm_gpuva
+ * is invalidated
+ * @va: the &drm_gpuva to check
+ */
+static inline bool drm_gpuva_invalidated(struct drm_gpuva *va)
+{
+	return va->flags & DRM_GPUVA_INVALIDATED;
+}
+
+/**
+ * struct drm_gpuva_manager - DRM GPU VA Manager
+ *
+ * The DRM GPU VA Manager keeps track of a GPU's virtual address space by using
+ * &maple_tree structures. Typically, this structure is embedded in bigger
+ * driver structures.
+ *
+ * Drivers can pass addresses and ranges in an arbitrary unit, e.g. bytes or
+ * pages.
+ *
+ * There should be one manager instance per GPU virtual address space.
+ */
+struct drm_gpuva_manager {
+	/**
+	 * @name: the name of the DRM GPU VA space
+	 */
+	const char *name;
+
+	/**
+	 * @mm_start: start of the VA space
+	 */
+	u64 mm_start;
+
+	/**
+	 * @mm_range: length of the VA space
+	 */
+	u64 mm_range;
+
+	/**
+	 * @mtree: the &maple_tree to track GPU VA mappings
+	 */
+	struct maple_tree mtree;
+
+	/**
+	 * @kernel_alloc_node:
+	 *
+	 * &drm_gpuva representing the address space cutout reserved for
+	 * the kernel
+	 */
+	struct drm_gpuva kernel_alloc_node;
+
+	/**
+	 * @ops: &drm_gpuva_fn_ops providing the split/merge steps to drivers
+	 */
+	const struct drm_gpuva_fn_ops *ops;
+};
+
+void drm_gpuva_manager_init(struct drm_gpuva_manager *mgr,
+			    const char *name,
+			    u64 start_offset, u64 range,
+			    u64 reserve_offset, u64 reserve_range,
+			    const struct drm_gpuva_fn_ops *ops);
+void drm_gpuva_manager_destroy(struct drm_gpuva_manager *mgr);
+
+/**
+ * struct drm_gpuva_prealloc - holds a preallocated node for the
+ * &drm_gpuva_manager to insert a single new entry
+ */
+struct drm_gpuva_prealloc {
+	/**
+	 * @mas: the maple tree advanced state
+	 */
+	struct ma_state mas;
+};
+
+struct drm_gpuva_prealloc * drm_gpuva_prealloc_create(struct drm_gpuva_manager *mgr);
+void drm_gpuva_prealloc_destroy(struct drm_gpuva_prealloc *pa);
+
+/**
+ * struct drm_gpuva_iterator - iterator for walking the internal (maple) tree
+ */
+struct drm_gpuva_iterator {
+	/**
+	 * @mas: the maple tree advanced state
+	 */
+	struct ma_state mas;
+
+	/**
+	 * @mgr: the &drm_gpuva_manager to iterate
+	 */
+	struct drm_gpuva_manager *mgr;
+};
+typedef struct drm_gpuva_iterator * drm_gpuva_state_t;
+
+void drm_gpuva_iter_remove(struct drm_gpuva_iterator *it);
+int drm_gpuva_iter_va_replace(struct drm_gpuva_iterator *it,
+			      struct drm_gpuva *va);
+
+static inline struct drm_gpuva *
+drm_gpuva_iter_find(struct drm_gpuva_iterator *it, unsigned long max)
+{
+	struct drm_gpuva *va;
+
+	mas_lock(&it->mas);
+	va = mas_find(&it->mas, max);
+	mas_unlock(&it->mas);
+
+	return va;
+}
+
+/**
+ * DRM_GPUVA_ITER - create an iterator structure to iterate the &drm_gpuva tree
+ * @name: the name of the &drm_gpuva_iterator to create
+ * @mgr__: the &drm_gpuva_manager to iterate
+ * @start: starting offset, the first entry will overlap this
+ */
+#define DRM_GPUVA_ITER(name, mgr__, start)				\
+	struct drm_gpuva_iterator name = {				\
+		.mas = MA_STATE_INIT(&(mgr__)->mtree, start, 0),	\
+		.mgr = mgr__,						\
+	}
+
+/**
+ * drm_gpuva_iter_for_each_range - iternator to walk over a range of entries
+ * @va__: the &drm_gpuva found for the current iteration
+ * @it__: &drm_gpuva_iterator structure to assign to in each iteration step
+ * @end__: ending offset, the last entry will start before this (but may overlap)
+ *
+ * This function can be used to iterate &drm_gpuva objects.
+ *
+ * It is safe against the removal of elements using &drm_gpuva_iter_remove,
+ * however it is not safe against the removal of elements using
+ * &drm_gpuva_remove.
+ */
+#define drm_gpuva_iter_for_each_range(va__, it__, end__) \
+	while (((va__) = drm_gpuva_iter_find(&(it__), (end__) - 1)))
+
+/**
+ * drm_gpuva_iter_for_each - iternator to walk over all existing entries
+ * @va__: the &drm_gpuva found for the current iteration
+ * @it__: &drm_gpuva_iterator structure to assign to in each iteration step
+ *
+ * This function can be used to iterate &drm_gpuva objects.
+ *
+ * In order to walk over all potentially existing entries, the
+ * &drm_gpuva_iterator must be initialized to start at
+ * &drm_gpuva_manager->mm_start or simply 0.
+ *
+ * It is safe against the removal of elements using &drm_gpuva_iter_remove,
+ * however it is not safe against the removal of elements using
+ * &drm_gpuva_remove.
+ */
+#define drm_gpuva_iter_for_each(va__, it__) \
+	drm_gpuva_iter_for_each_range(va__, it__, (it__).mgr->mm_start + (it__).mgr->mm_range)
+
+/**
+ * enum drm_gpuva_op_type - GPU VA operation type
+ *
+ * Operations to alter the GPU VA mappings tracked by the &drm_gpuva_manager.
+ */
+enum drm_gpuva_op_type {
+	/**
+	 * @DRM_GPUVA_OP_MAP: the map op type
+	 */
+	DRM_GPUVA_OP_MAP,
+
+	/**
+	 * @DRM_GPUVA_OP_REMAP: the remap op type
+	 */
+	DRM_GPUVA_OP_REMAP,
+
+	/**
+	 * @DRM_GPUVA_OP_UNMAP: the unmap op type
+	 */
+	DRM_GPUVA_OP_UNMAP,
+
+	/**
+	 * @DRM_GPUVA_OP_PREFETCH: the prefetch op type
+	 */
+	DRM_GPUVA_OP_PREFETCH,
+};
+
+/**
+ * struct drm_gpuva_op_map - GPU VA map operation
+ *
+ * This structure represents a single map operation generated by the
+ * DRM GPU VA manager.
+ */
+struct drm_gpuva_op_map {
+	/**
+	 * @va: structure containing address and range of a map
+	 * operation
+	 */
+	struct {
+		/**
+		 * @addr: the base address of the new mapping
+		 */
+		u64 addr;
+
+		/**
+		 * @range: the range of the new mapping
+		 */
+		u64 range;
+	} va;
+
+	/**
+	 * @gem: structure containing the &drm_gem_object and it's offset
+	 */
+	struct {
+		/**
+		 * @offset: the offset within the &drm_gem_object
+		 */
+		u64 offset;
+
+		/**
+		 * @obj: the &drm_gem_object to map
+		 */
+		struct drm_gem_object *obj;
+	} gem;
+};
+
+/**
+ * struct drm_gpuva_op_unmap - GPU VA unmap operation
+ *
+ * This structure represents a single unmap operation generated by the
+ * DRM GPU VA manager.
+ */
+struct drm_gpuva_op_unmap {
+	/**
+	 * @va: the &drm_gpuva to unmap
+	 */
+	struct drm_gpuva *va;
+
+	/**
+	 * @keep:
+	 *
+	 * Indicates whether this &drm_gpuva is physically contiguous with the
+	 * original mapping request.
+	 *
+	 * Optionally, if &keep is set, drivers may keep the actual page table
+	 * mappings for this &drm_gpuva, adding the missing page table entries
+	 * only and update the &drm_gpuva_manager accordingly.
+	 */
+	bool keep;
+};
+
+/**
+ * struct drm_gpuva_op_remap - GPU VA remap operation
+ *
+ * This represents a single remap operation generated by the DRM GPU VA manager.
+ *
+ * A remap operation is generated when an existing GPU VA mmapping is split up
+ * by inserting a new GPU VA mapping or by partially unmapping existent
+ * mapping(s), hence it consists of a maximum of two map and one unmap
+ * operation.
+ *
+ * The @unmap operation takes care of removing the original existing mapping.
+ * @prev is used to remap the preceding part, @next the subsequent part.
+ *
+ * If either a new mapping's start address is aligned with the start address
+ * of the old mapping or the new mapping's end address is aligned with the
+ * end address of the old mapping, either @prev or @next is NULL.
+ *
+ * Note, the reason for a dedicated remap operation, rather than arbitrary
+ * unmap and map operations, is to give drivers the chance of extracting driver
+ * specific data for creating the new mappings from the unmap operations's
+ * &drm_gpuva structure which typically is embedded in larger driver specific
+ * structures.
+ */
+struct drm_gpuva_op_remap {
+	/**
+	 * @prev: the preceding part of a split mapping
+	 */
+	struct drm_gpuva_op_map *prev;
+
+	/**
+	 * @next: the subsequent part of a split mapping
+	 */
+	struct drm_gpuva_op_map *next;
+
+	/**
+	 * @unmap: the unmap operation for the original existing mapping
+	 */
+	struct drm_gpuva_op_unmap *unmap;
+};
+
+/**
+ * struct drm_gpuva_op_prefetch - GPU VA prefetch operation
+ *
+ * This structure represents a single prefetch operation generated by the
+ * DRM GPU VA manager.
+ */
+struct drm_gpuva_op_prefetch {
+	/**
+	 * @va: the &drm_gpuva to prefetch
+	 */
+	struct drm_gpuva *va;
+};
+
+/**
+ * struct drm_gpuva_op - GPU VA operation
+ *
+ * This structure represents a single generic operation.
+ *
+ * The particular type of the operation is defined by @op.
+ */
+struct drm_gpuva_op {
+	/**
+	 * @entry:
+	 *
+	 * The &list_head used to distribute instances of this struct within
+	 * &drm_gpuva_ops.
+	 */
+	struct list_head entry;
+
+	/**
+	 * @op: the type of the operation
+	 */
+	enum drm_gpuva_op_type op;
+
+	union {
+		/**
+		 * @map: the map operation
+		 */
+		struct drm_gpuva_op_map map;
+
+		/**
+		 * @remap: the remap operation
+		 */
+		struct drm_gpuva_op_remap remap;
+
+		/**
+		 * @unmap: the unmap operation
+		 */
+		struct drm_gpuva_op_unmap unmap;
+
+		/**
+		 * @prefetch: the prefetch operation
+		 */
+		struct drm_gpuva_op_prefetch prefetch;
+	};
+};
+
+/**
+ * struct drm_gpuva_ops - wraps a list of &drm_gpuva_op
+ */
+struct drm_gpuva_ops {
+	/**
+	 * @list: the &list_head
+	 */
+	struct list_head list;
+};
+
+/**
+ * drm_gpuva_for_each_op - iterator to walk over &drm_gpuva_ops
+ * @op: &drm_gpuva_op to assign in each iteration step
+ * @ops: &drm_gpuva_ops to walk
+ *
+ * This iterator walks over all ops within a given list of operations.
+ */
+#define drm_gpuva_for_each_op(op, ops) list_for_each_entry(op, &(ops)->list, entry)
+
+/**
+ * drm_gpuva_for_each_op_safe - iterator to safely walk over &drm_gpuva_ops
+ * @op: &drm_gpuva_op to assign in each iteration step
+ * @next: &next &drm_gpuva_op to store the next step
+ * @ops: &drm_gpuva_ops to walk
+ *
+ * This iterator walks over all ops within a given list of operations. It is
+ * implemented with list_for_each_safe(), so save against removal of elements.
+ */
+#define drm_gpuva_for_each_op_safe(op, next, ops) \
+	list_for_each_entry_safe(op, next, &(ops)->list, entry)
+
+/**
+ * drm_gpuva_for_each_op_from_reverse - iterate backwards from the given point
+ * @op: &drm_gpuva_op to assign in each iteration step
+ * @ops: &drm_gpuva_ops to walk
+ *
+ * This iterator walks over all ops within a given list of operations beginning
+ * from the given operation in reverse order.
+ */
+#define drm_gpuva_for_each_op_from_reverse(op, ops) \
+	list_for_each_entry_from_reverse(op, &(ops)->list, entry)
+
+/**
+ * drm_gpuva_first_op - returns the first &drm_gpuva_op from &drm_gpuva_ops
+ * @ops: the &drm_gpuva_ops to get the fist &drm_gpuva_op from
+ */
+#define drm_gpuva_first_op(ops) \
+	list_first_entry(&(ops)->list, struct drm_gpuva_op, entry)
+
+/**
+ * drm_gpuva_last_op - returns the last &drm_gpuva_op from &drm_gpuva_ops
+ * @ops: the &drm_gpuva_ops to get the last &drm_gpuva_op from
+ */
+#define drm_gpuva_last_op(ops) \
+	list_last_entry(&(ops)->list, struct drm_gpuva_op, entry)
+
+/**
+ * drm_gpuva_prev_op - previous &drm_gpuva_op in the list
+ * @op: the current &drm_gpuva_op
+ */
+#define drm_gpuva_prev_op(op) list_prev_entry(op, entry)
+
+/**
+ * drm_gpuva_next_op - next &drm_gpuva_op in the list
+ * @op: the current &drm_gpuva_op
+ */
+#define drm_gpuva_next_op(op) list_next_entry(op, entry)
+
+struct drm_gpuva_ops *
+drm_gpuva_sm_map_ops_create(struct drm_gpuva_manager *mgr,
+			    u64 addr, u64 range,
+			    struct drm_gem_object *obj, u64 offset);
+struct drm_gpuva_ops *
+drm_gpuva_sm_unmap_ops_create(struct drm_gpuva_manager *mgr,
+			      u64 addr, u64 range);
+
+struct drm_gpuva_ops *
+drm_gpuva_prefetch_ops_create(struct drm_gpuva_manager *mgr,
+				 u64 addr, u64 range);
+
+struct drm_gpuva_ops *
+drm_gpuva_gem_unmap_ops_create(struct drm_gpuva_manager *mgr,
+			       struct drm_gem_object *obj);
+
+void drm_gpuva_ops_free(struct drm_gpuva_manager *mgr,
+			struct drm_gpuva_ops *ops);
+
+/**
+ * struct drm_gpuva_fn_ops - callbacks for split/merge steps
+ *
+ * This structure defines the callbacks used by &drm_gpuva_sm_map and
+ * &drm_gpuva_sm_unmap to provide the split/merge steps for map and unmap
+ * operations to drivers.
+ */
+struct drm_gpuva_fn_ops {
+	/**
+	 * @op_alloc: called when the &drm_gpuva_manager allocates
+	 * a struct drm_gpuva_op
+	 *
+	 * Some drivers may want to embed struct drm_gpuva_op into driver
+	 * specific structures. By implementing this callback drivers can
+	 * allocate memory accordingly.
+	 *
+	 * This callback is optional.
+	 */
+	struct drm_gpuva_op *(*op_alloc)(void);
+
+	/**
+	 * @op_free: called when the &drm_gpuva_manager frees a
+	 * struct drm_gpuva_op
+	 *
+	 * Some drivers may want to embed struct drm_gpuva_op into driver
+	 * specific structures. By implementing this callback drivers can
+	 * free the previously allocated memory accordingly.
+	 *
+	 * This callback is optional.
+	 */
+	void (*op_free)(struct drm_gpuva_op *op);
+
+	/**
+	 * @sm_step_map: called from &drm_gpuva_sm_map to finally insert the
+	 * mapping once all previous steps were completed
+	 *
+	 * The &priv pointer matches the one the driver passed to
+	 * &drm_gpuva_sm_map or &drm_gpuva_sm_unmap, respectively.
+	 *
+	 * Can be NULL if &drm_gpuva_sm_map is used.
+	 */
+	int (*sm_step_map)(struct drm_gpuva_op *op, void *priv);
+
+	/**
+	 * @sm_step_remap: called from &drm_gpuva_sm_map and
+	 * &drm_gpuva_sm_unmap to split up an existent mapping
+	 *
+	 * This callback is called when existent mapping needs to be split up.
+	 * This is the case when either a newly requested mapping overlaps or
+	 * is enclosed by an existent mapping or a partial unmap of an existent
+	 * mapping is requested.
+	 *
+	 * Drivers must not modify the GPUVA space with accessors that do not
+	 * take a &drm_gpuva_state as argument from this callback.
+	 *
+	 * The &priv pointer matches the one the driver passed to
+	 * &drm_gpuva_sm_map or &drm_gpuva_sm_unmap, respectively.
+	 *
+	 * Can be NULL if neither &drm_gpuva_sm_map nor &drm_gpuva_sm_unmap is
+	 * used.
+	 */
+	int (*sm_step_remap)(struct drm_gpuva_op *op,
+			     drm_gpuva_state_t state,
+			     void *priv);
+
+	/**
+	 * @sm_step_unmap: called from &drm_gpuva_sm_map and
+	 * &drm_gpuva_sm_unmap to unmap an existent mapping
+	 *
+	 * This callback is called when existent mapping needs to be unmapped.
+	 * This is the case when either a newly requested mapping encloses an
+	 * existent mapping or an unmap of an existent mapping is requested.
+	 *
+	 * Drivers must not modify the GPUVA space with accessors that do not
+	 * take a &drm_gpuva_state as argument from this callback.
+	 *
+	 * The &priv pointer matches the one the driver passed to
+	 * &drm_gpuva_sm_map or &drm_gpuva_sm_unmap, respectively.
+	 *
+	 * Can be NULL if neither &drm_gpuva_sm_map nor &drm_gpuva_sm_unmap is
+	 * used.
+	 */
+	int (*sm_step_unmap)(struct drm_gpuva_op *op,
+			     drm_gpuva_state_t state,
+			     void *priv);
+};
+
+int drm_gpuva_sm_map(struct drm_gpuva_manager *mgr, void *priv,
+		     u64 addr, u64 range,
+		     struct drm_gem_object *obj, u64 offset);
+
+int drm_gpuva_sm_unmap(struct drm_gpuva_manager *mgr, void *priv,
+		       u64 addr, u64 range);
+
+int drm_gpuva_map(struct drm_gpuva_manager *mgr,
+		  struct drm_gpuva_prealloc *pa,
+		  struct drm_gpuva *va);
+int drm_gpuva_remap(drm_gpuva_state_t state,
+		    struct drm_gpuva *prev,
+		    struct drm_gpuva *next);
+void drm_gpuva_unmap(drm_gpuva_state_t state);
+
+#endif /* __DRM_GPUVA_MGR_H__ */