drivers/gpu/drm/xe/xe_vm_doc.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/xe/xe_vm_doc.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/xe/xe_vm_doc.h- Extension
.h- Size
- 24846 bytes
- Lines
- 556
- Domain
- Driver Families
- Bucket
- drivers/gpu
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#ifndef _XE_VM_DOC_H_
#define _XE_VM_DOC_H_
/**
* DOC: Xe VM (user address space)
*
* VM creation
* ===========
*
* Allocate a physical page for root of the page table structure, create default
* bind engine, and return a handle to the user.
*
* Scratch page
* ------------
*
* If the VM is created with the flag, DRM_XE_VM_CREATE_FLAG_SCRATCH_PAGE, set the
* entire page table structure defaults pointing to blank page allocated by the
* VM. Invalid memory access rather than fault just read / write to this page.
*
* VM bind (create GPU mapping for a BO or userptr)
* ================================================
*
* Creates GPU mappings for a BO or userptr within a VM. VM binds uses the same
* in / out fence interface (struct drm_xe_sync) as execs which allows users to
* think of binds and execs as more or less the same operation.
*
* Operations
* ----------
*
* DRM_XE_VM_BIND_OP_MAP - Create mapping for a BO
* DRM_XE_VM_BIND_OP_UNMAP - Destroy mapping for a BO / userptr
* DRM_XE_VM_BIND_OP_MAP_USERPTR - Create mapping for userptr
*
* Implementation details
* ~~~~~~~~~~~~~~~~~~~~~~
*
* All bind operations are implemented via a hybrid approach of using the CPU
* and GPU to modify page tables. If a new physical page is allocated in the
* page table structure we populate that page via the CPU and insert that new
* page into the existing page table structure via a GPU job. Also any existing
* pages in the page table structure that need to be modified also are updated
* via the GPU job. As the root physical page is prealloced on VM creation our
* GPU job will always have at least 1 update. The in / out fences are passed to
* this job so again this is conceptually the same as an exec.
*
* Very simple example of few binds on an empty VM with 48 bits of address space
* and the resulting operations:
*
* .. code-block::
*
* bind BO0 0x0-0x1000
* alloc page level 3a, program PTE[0] to BO0 phys address (CPU)
* alloc page level 2, program PDE[0] page level 3a phys address (CPU)
* alloc page level 1, program PDE[0] page level 2 phys address (CPU)
* update root PDE[0] to page level 1 phys address (GPU)
*
* bind BO1 0x201000-0x202000
* alloc page level 3b, program PTE[1] to BO1 phys address (CPU)
* update page level 2 PDE[1] to page level 3b phys address (GPU)
*
* bind BO2 0x1ff000-0x201000
* update page level 3a PTE[511] to BO2 phys address (GPU)
* update page level 3b PTE[0] to BO2 phys address + 0x1000 (GPU)
*
* GPU bypass
* ~~~~~~~~~~
*
* In the above example the steps using the GPU can be converted to CPU if the
* bind can be done immediately (all in-fences satisfied, VM dma-resv kernel
* slot is idle).
*
* Address space
* -------------
*
* Depending on platform either 48 or 57 bits of address space is supported.
*
* Page sizes
* ----------
*
* The minimum page size is either 4k or 64k depending on platform and memory
* placement (sysmem vs. VRAM). We enforce that binds must be aligned to the
* minimum page size.
*
* Larger pages (2M or 1GB) can be used for BOs in VRAM, the BO physical address
* is aligned to the larger pages size, and VA is aligned to the larger page
* size. Larger pages for userptrs / BOs in sysmem should be possible but is not
* yet implemented.
*
* Sync error handling mode
* ------------------------
Annotation
- Atlas domain: Driver Families / drivers/gpu.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.