Add a motivation for and description of asynchronous VM_BIND operation

v2:
- Fix typos (Nirmoy Das)
- Improve the description of a memory fence (Oak Zeng)
- Add a reference to the document in the Xe RFC.
- Add pointers to sample uAPI suggestions
v3:
- Address review comments (Danilo Krummrich)
- Formatting fixes
v4:
- Address typos (Francois Dugast)
- Explain why in-fences are not allowed for VM_BIND operations for long-
  running workloads (Matthew Brost)
v5:
- More typo- and style fixing
- Further clarify the implications of disallowing in-fences for VM_BIND
  operations for long-running workloads (Matthew Brost)
v6:
- Point out that a gpu_vm is a virtual GPU Address space.
  (Danilo Krummrich)
- For an explanation of dma-fences point to the dma-fence documentation.
  (Paulo Zanoni)
- Clarify that VM_BIND errors are reported synchronously. (Paulo Zanoni)
- Use an rst doc reference when pointing to the async vm_bind document
  from the xe merge plan.
- Add the VM_BIND documentation to the drm documentation table-of-content,
  using an intermediate "Misc DRM driver uAPI- and feature implementation
  guidelines"
v7:
- Update the error handling documentation to remove the VM error state.
v8:
- Clarify error handling and difference in operation support between
  async VM_BIND and sync VM_BIND. (Paulo Zanoni)
- Update the sample uAPI with a self-contained example. (Paulo Zanoni)

Cc: Paulo R Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Danilo Krummrich <dakr@redhat.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231012132552.20196-1-thomas.hellstrom@linux.intel.com

Nouveau has landed the GPU VA helpers, support and documentation
already and Xe is already using the upstream GPU VA.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/commit/ea4ae69e66b2940107e74f240ecb9dae87bf1ff1
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/commits/drm-xe-next?ref_type=heads
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Danilo Krummrich <dakr@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-4-rodrigo.vivi@intel.com

The consensus is for individual drivers VM_BIND uapis with
the GPUVA helpers that are already implemented and merged
upstream.

The merged GPUVA documentation also establish some overall
rules for the locking to be followed by the drivers.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Danilo Krummrich <dakr@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-3-rodrigo.vivi@intel.com

Xe is already using devcoredump infrastructure as the primary
error state and all the changes needed for user space error
replay and other useful logs are getting added into xe_devcoredump.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-next/drivers/gpu/drm/xe/xe_devcoredump.c
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-2-rodrigo.vivi@intel.com

Also the uapi should be reviewed and scrutinized before xe
is accepted upstream and we shouldn't cause regression.

Link: https://lore.kernel.org/all/20230630100059.122881-1-thomas.hellstrom@linux.intel.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-1-rodrigo.vivi@intel.com

Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in
order to avoid unnecessary delays.

This initial document starts with a TODO list containing items with clear and
measurable key results. Xe’s initial pull request should only be sent to
dri-devel after all the items are clearly resolved.

Since many of them involve some level of a community consensus, in many cases,
the consensus will be reached in follow-up patches to this document with more
details of the API or helpers that will be developed or modified.

Besides of the items that are highlighted in this document, it is important
to highlight that Oded, has been volunteered to give the overall ack on Xe
driver as the way to confirm that it looks good for upstream.

v2: Incorporated Daniel's feedback:
    - Do not make long-running compute a blocker.
    - Add a mention to drm-exec that that ties to vm_bind and long-running
      compute jobs. Then I also added GPUVA since I recently noticed that this
      ties also to the work Matt is doing on that front.
    - Added the devcoredump section.
    - Add the mention to Oded being volunteered for the overall ack.

v3: Reword a bit the Async VM_BIND to incorporate Daniel's feedback on ensuring
    the async vmbind consensus explicitly include Mesa, besides other kernel
    drivers.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Signed-off-by: Luis Strano <luis.strano@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230419191913.158807-1-rodrigo.vivi@intel.com