public inbox for dri-devel@lists.freedesktop.org
 help / color / mirror / Atom feed
* [RFC V2 00/12] drm/amdgpu: SVM implementation based on drm_gpusvm
@ 2026-04-20 12:07 Honglei Huang
  2026-04-20 12:07 ` [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions Honglei Huang
                   ` (11 more replies)
  0 siblings, 12 replies; 37+ messages in thread
From: Honglei Huang @ 2026-04-20 12:07 UTC (permalink / raw)
  To: Alexander.Deucher, Felix.Kuehling, Christian.Koenig, Oak.Zeng,
	Jenny-Jing.Liu, Philip.Yang, Xiaogang.Chen, Ray.Huang,
	Lingshan.Zhu, Junhua.Shen, matthew.brost, rodrigo.vivi,
	thomas.hellstrom, dakr, aliceryhl
  Cc: amd-gfx, dri-devel, honghuan

From: Honglei Huang <honghuan@amd.com>

V2 of the SVM patch series for amdgpu based on the drm_gpusvm framework. 
This revision incorporates feedback from V1, adds XNACK on GPU fault handling,
improves code organization, and removes the XNACK off (no GPU fault) implementation
to focus on the fault driven model that aligns with drm_gpusvm's design. 
The implementation references extensively from xe_svm.

This patch series implements SVM support with the following design:

  1. Attributes separated from physical page management:

    - Attribute layer (amdgpu_svm_attr_tree): a driver-side interval
      tree storing per-range SVM attributes. Managed through SET_ATTR
      ioctl and preserved across range lifecycle events.

    - Physical page layer (drm_gpusvm ranges): managed by the
      drm_gpusvm framework, representing HMM-backed DMA mappings
      and GPU page table entries.

    This separation ensures attributes survive when GPU ranges are
    destroyed (partial munmap, attribute split, GC). The fault
    handler recreates GPU ranges from the attribute tree on demand.

  2. GPU fault driven mapping (XNACK on):

    The core mapping path is driven by GPU page faults instead of ioctls.
    amdgpu_svm_handle_fault() looks up SVM by PASID, runs GC,
    resolves attributes, then maps via find_or_insert -> get_pages
    -> GPU PTE update. For unregistered addresses, default
    attributes are derived from VMA properties automatically.

  3. MMU notifier invalidation:

    Two-phase callback: event_begin() zaps GPU PTEs and flushes
    TLB, event_end() unmaps DMA pages. UNMAP events queue ranges
    to GC for deferred cleanup. Non-UNMAP events (eviction) rely
    on GPU fault to remap.

  4. Garbage collector:

    GC workqueue processes unmapped ranges: removes them
    from drm_gpusvm and clears corresponding attributes. No
    rebuild or restore logic, GPU fault handles recreation.

Changes since V1:
  - Added GPU fault handler: amdgpu_svm_handle_fault with PASID-based
    SVM lookup, following the standard flow: garbage collector ->
    find or insert range -> check valid -> migrate (TODO) / get_pages
    -> GPU bind/map.

  - Removed the restore worker queue entirely. V1 had separate GC
    and restore workers: restore workers were responsible for 
    synchronously restore in queue stop/start cause no GPU fault support.
    With XNACK on fault driven model, synchronous restore is unnecessary,
    the GPU fault handler recreates ranges on demand. The GC worker in 
    V2 is simplified to only discard ranges and clear their attributes, 
    with no rebuild or restore logic. AMDGPU_SVM_FLAG_GPU_ALWAYS_MAPPED
    support is removed as no restore worker.

  - Reworked MMU notifier callback (amdgpu_svm_range_invalidate):
    V1 had a monolithic dispatcher with flag combinations and
    queue ops (CLEAR_PTE/QUEUE_INTERVAL, UNMAP/RESTORE) plus
    begin_restore() to quiesce KFD queues. V2 uses a two-phase
    model: event_begin() zaps GPU PTEs and flushes TLB,
    event_end() unmaps DMA pages and queues UNMAP ranges to GC.
    Non-UNMAP events (eviction) just zap PTEs and let GPU fault
    remap. Removed begin_restore/end_restore callbacks,
    has_always_mapped_range() check, and NOTIFIER flag dispatch.
    Added checkpoint timestamp capture on UNMAP for fault dedup.

  - Added amdgpu_svm_range_invalidate_interval(): when userspace
    sets new attributes on a sub region of an existing attribute
    range, the attribute tree splits the old range and the new
    sub region gets different attributes. However, existing
    drm_gpusvm ranges may across the new attribute boundary
    (e.g., a 2M GPU range covers both the old and new attribute
    regions). This function walks all gpusvm ranges in the
    affected interval, zaps GPU PTEs and flushes TLB. Ranges
    that cross the new boundary and old boundary are removed 
    entirely so the GPU fault handler can recreate them with 
    boundaries aligned to the updated attribute layout.

  - On MMU_NOTIFY_UNMAP events, discard all affected gpusvm ranges
    entirely without synchronous rebuild in v1. The unmap may destroy
    more ranges than strictly necessary (e.g., a partial munmap
    hits a 2M range that extends beyond the unmapped region), but
    the attribute layer preserves the still valid attributes for
    the remaining address space. When the GPU next accesses those
    addresses, the fault handler automatically recreates the
    ranges with correct boundaries from the surviving attributes.
    This avoids the synchronous rebuild logic that V1 required 
    (unmap -> rebuild in GC/restore worker).

  - Add attribute creation for unregistered addresses:
    amdgpu_svm_range_get_unregistered_attrs() derives default
    SVM attributes from VMA properties and GPU IP capabilities
    when the faulting address has no user attributes registered.
    this feature is needed to pass ROCm user mode runtime tests:
    kfd/rocr/hip. ROCm supports no registered virtual address access
    with default SVM attributes before, so amdgpu svm needs to support.

  - Explicitly returns -EOPNOTSUPP in amdgpu_svm_init when XNACK
    is disabled. V1 attempted mixed XNACK on/off support with
    complex KFD queue quiesce/resume callbacks and ioctl driven
    mapping paths, which added substantial complexity. V2 drops
    these implementations to focus on the fault driven model.

  - Removed kgd2kfd_quiesce_mm()/resume_mm() dependency that V1
    used for XNACK off queue control. For XNACK on, the GPU fault 
    handler is the enterance for SVM range mapping, so no quiesce/resume
    is needed for this version. 

  - Added new change triggers: TRIGGER_RANGE_SPLIT, TRIGGER_PREFETCH.
    for sub attr set and prefetch trigger support.

  - Added helper functions: find_locked, get_bounds_locked,
    set_default for GPU fault handling.

  - Design questions section removed.

TODO:
  - Add multi GPU support.
  - Add XNACK off mode.
  - Add migration or prefetch. This part work is ongoing in:
    https://lore.kernel.org/amd-gfx/20260410113146.146212-1-Junhua.Shen@amd.com/

Test results:
  Tested on gfx943 (MI300X) and gfx906 (MI60) with XNACK on:
  - KFD test: 95%+ passed.
  - ROCR test: all passed.
  - HIP catch test: gfx943 (MI300X): 96% passed.
                    gfx906 (MI60):99% passed.

Patch overview:

  01/12 UAPI: DRM_AMDGPU_GEM_SVM ioctl, SVM flags, SET_ATTR/GET_ATTR
        operations, attribute types in amdgpu_drm.h.

  02/12 Core header: amdgpu_svm wrapping drm_gpusvm with refcount,
        attr_tree, GC struct, locks, and VM integration hooks.

  03/12 Attribute types: amdgpu_svm_attrs, attr_range (interval tree
        node), attr_tree, access enum, flag masks, change triggers.

  04/12 Attribute tree ops: interval tree lookup, insert, remove,
        find_locked, get_bounds_locked, set_default, and lifecycle.

  05/12 Attribute set/get/clear: validate UAPI attributes, apply to
        tree with head/tail splitting, change propagation, and query.

  06/12 Range types: amdgpu_svm_range extending drm_gpusvm_range
        with gpu_mapped state, pending ops, work queue linkage,
        and op_ctx for batch processing.

  07/12 Range GPU mapping: PTE flags computation with read_only
        support, GPU page table update, range mapping loop.

  08/12 Notifier and GC helpers: two-phase notifier events, range
        removal, GC enqueue/add with dedicated workqueue.

  09/12 Attribute change and invalidation: apply attribute triggers
        to GPU ranges, invalidate_interval for boundary realignment,
        work queue dequeue helpers, checkpoint timestamp.

  10/12 Initialization and lifecycle: kmem_cache, drm_gpusvm_init
        with chunk sizes (2M/64K/4K), XNACK detection, GC init,
        PASID lookup, TLB flush, and init/close/fini lifecycle.

  11/12 Ioctl, GC, and fault handler: ioctl dispatcher, GC worker,
        and amdgpu_svm_fault.c/h with full fault path including
        unregistered attribute derivation and retry logic.

  12/12 Build integration: Kconfig (CONFIG_DRM_AMDGPU_SVM), Makefile
        rules, ioctl registration, and amdgpu_vm fault dispatch.

Honglei Huang (12):
  drm/amdgpu: add SVM UAPI definitions
  drm/amdgpu: add SVM data structures and header
  drm/amdgpu: add SVM attribute data structures
  drm/amdgpu: implement SVM attribute tree operations
  drm/amdgpu: implement SVM attribute set
  drm/amdgpu: add SVM range data structures
  drm/amdgpu: implement SVM range PTE flags and GPU mapping
  drm/amdgpu: implement SVM range notifier and invalidation
  drm/amdgpu: implement SVM range workers
  drm/amdgpu: implement SVM core initialization and fini
  drm/amdgpu: implement SVM ioctl and fault handler
  drm/amdgpu: wire up SVM build system and fault handler

 drivers/gpu/drm/amd/amdgpu/Kconfig            |   11 +
 drivers/gpu/drm/amd/amdgpu/Makefile           |   13 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c       |    2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.c       |  430 ++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.h       |  147 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.c  |  894 ++++++++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.h  |  110 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.c | 1196 +++++++++++++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.h |   76 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c        |   40 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h        |    4 +
 include/uapi/drm/amdgpu_drm.h                 |   39 +
 12 files changed, 2958 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.h


base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
-- 
2.34.1


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [RFC/POC PATCH 00/12] POC SVM implementation in AMDGPU based on drm_gpusvm
@ 2026-03-17 11:29 Honglei Huang
  2026-03-17 11:29 ` [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions Honglei Huang
  0 siblings, 1 reply; 37+ messages in thread
From: Honglei Huang @ 2026-03-17 11:29 UTC (permalink / raw)
  To: Alexander.Deucher, Felix.Kuehling, Christian.Koenig, Oak.Zeng,
	Jenny-Jing.Liu, Philip.Yang, Xiaogang.Chen, Ray.Huang,
	Lingshan.Zhu, Junhua.Shen
  Cc: amd-gfx, dri-devel, honghuan

From: Honglei Huang <honghuan@amd.com>

This is a POC/draft patch series of SVM feature in amdgpu based on the 
drm_gpusvm framework. The primary purpose of this RFC is to validate
the framework's applicability, identify implementation challenges, 
and start discussion on framework evolution. This is not a production 
ready submission.

This patch series implements basic SVM support with the following features:

  1. attributes sepatarated from physical page management:

    - Attribute layer (amdgpu_svm_attr_tree): a driver side interval
      tree that stores SVM attributes. Managed through the SET_ATTR,
      and mmu notifier callback.

    - Physical page layer (drm_gpusvm ranges): managed by the
      drm_gpusvm framework, representing actual HMM backed DMA
      mappings and GPU page table entries.

     This separation is necessary:
       -  The framework does not support range splitting, so a partial 
          munmap destroys the entire overlapping range, including the 
          still valid parts. If attributes were stored inside drm_gpusvm
          ranges, they would be lost on unmapping.
          The separate attr tree preserves userspace set attributes
          across range operations.

       -  drm_gpusvm range boundaries are determined by fault address
          and pre setted chunk size, not by userspace attribute boundaries.
          Ranges  may be rechunked on memory changes. Embedding
          attributes in framework ranges would scatter attr state
          across many small ranges and require complex reassemble
          logic when operate attrbute.

  2) System memory mapping via drm_gpusvm

     The core mapping path uses drm_gpusvm_range_find_or_insert() to
     create ranges, drm_gpusvm_range_get_pages() for HMM page fault
     and DMA mapping, then updates GPU page tables via
     amdgpu_vm_update_range().

  3) IOCTL driven mapping (XNACK off / no GPU fault mode)

     On XNACK off hardware the GPU cannot recover from page faults,
     so mappings must be established through ioctl. When
     userspace calls SET_ATTR with ACCESS=ENABLE, the driver 
     walks the attr tree and maps all accessible intervals 
     to the GPU by amdgpu_svm_range_map_attr_ranges(). 

  4) Invalidation, GC worker, and restore worker

     MMU notifier callbacks (amdgpu_svm_range_invalidate) handle
     three cases based on event type and hardware mode:
       - unmap event: clear GPU PTEs in the notifier context,
         unmap DMA pages, mark ranges as unmapped, flush TLB,
         and enqueue to the GC worker. On XNACK off, also
         quiesce KFD queues and schedule rebuild of the
         still valid portions that were destroyed together with
         the unmapped subregion.

       - evict on XNACK off:
         quiesce KFD queues first, then unmap DMA pages and
         enqueue to the restore worker.

       - evict on XNACK on:
         clear GPU PTEs, unmap DMA pages, and flush TLB, but do
         not schedule any worker. The GPU will fault on next
         access and the fault handler establishes the mapping.

Not supported feature:
  - XNACK on GPU page fault mode
  - migration and prefetch feature
  - Multi GPU support

  XNACK on enablement is ongoing.The GPUs that support XNACK on 
  are currently only accessible to us via remote lab machines, which slows
  down progress.

Patch overview:

  01/12 UAPI definitions: DRM_AMDGPU_GEM_SVM ioctl, SVM flags,
        SET_ATTR/GET_ATTR operations, attribute types, and related
        structs in amdgpu_drm.h.

  02/12 Core data structures: amdgpu_svm wrapping drm_gpusvm with
        refcount, attr_tree, workqueues, locks, and
        callbacks (begin/end_restore, flush_tlb).

  03/12 Attribute data structures: amdgpu_svm_attrs, attr_range
        (interval tree node), attr_tree, access enum, flag masks,
        and change trigger enum.

  04/12 Attribute tree operations: interval tree lookup, insert,
        remove, and tree create/destroy lifecycle.

  05/12 Attribute set: validate UAPI attributes, apply to internal
        attrs, handle hole/existing range with head/tail splitting,
        compute change triggers, and -EAGAIN retry loop.
        Implements attr_clear_pages for unmap cleanup and attr_get.

  06/12 Range data structures: amdgpu_svm_range extending
        drm_gpusvm_range with gpu_mapped state, pending ops,
        pte_flags cache, and GC/restore queue linkage.

  07/12 PTE flags and GPU mapping: simple gpu pte function,
        GPU page table update with DMA address, range mapping loop:
        find_or_insert -> get_pages -> validate -> update PTE,
        and attribute change driven mapping function.

  08/12 Notifier and invalidation: synchronous GPU PTE clear in
        notifier context, range removal and overlap cleanup,
        rebuild after destroy logic, and MMU event dispatcher

  09/12 Workers: KFD queue quiesce/resume via kgd2kfd APIs, GC
        worker for unmap processing and rebuild, ordered restore
        worker for mapping evicted ranges, and flush/sync
        helpers.

  10/12 Initialization and fini: kmem_cache for range/attr,
        drm_gpusvm_init with chunk sizes, XNACK detection, TLB
        flush helper, and amdgpu_svm init/close/fini lifecycle.

  11/12 IOCTL and fault handler: PASID based SVM lookup with kref
        protection, amdgpu_gem_svm_ioctl dispatcher, and
        amdgpu_svm_handle_fault for GPU page fault recovery.

  12/12 Build integration: Kconfig option (CONFIG_DRM_AMDGPU_SVM),
        Makefile rules, ioctl table registration, and amdgpu_vm
        hooks (init in make_compute, close/fini, fault dispatch).

Test result:
  on gfx1100(W7900) and gfx943(MI300x)
  kfd test: 95%+ passed, same failed cases with offical relase
  rocr test: all passed
  hip catch test: 20 cases failed in all 5366 cases, +13 failures vs offical relase

During implementation we identified several challenges / design questions:

1. No range splitting on partial unmap

  drm_gpusvm explicitly does not support range splitting in drm_gpusvm.c:122.
  Partial munmap needs to destroy the entire range including the valid interval.
  GPU fault driven hardware can handle this design by extra gpu fault handle,
  but AMDGPU needs to support XNACK off hardware, this design requires driver 
  rebuild the valid part in the removed entire range. Whichs bring a very heavy
  restore work in work queue/GC worker: unmap/destroy -> rebuild(insert and map)
  this restore work even heavier than kfd_svm. In previous driver work queue 
  only needs to restore or unmap, but in drm_gpusvm driver needs to unmap and restore.
  which brings about more complex logic, heavier worker queue workload, and 
  synchronization issues.

2. Fault driven vs ioctl driven mapping

  drm_gpusvm is designed around GPU page fault handlers. The primary entry
  point drm_gpusvm_range_find_or_insert() takes a fault_addr.
  AMDGPU needs to support IOCTL driven mapping cause No XNACK hardware that
  GPU cannot fault at all

  The ioctl path cannot hold mmap_read_lock across the entire operation
  because drm_gpusvm_range_find_or_insert() acquires/releases it
  internally. This creates race windows with MMU notifiers / workers.

3. Multi GPU support

drm_gpusvm binds one drm_device to one instance. In multi GPU systems,
each GPU gets an independent instance with its own range tree, MMU
notifiers, notifier_lock, and DMA mappings.

This may brings huge overhead:
    - N x MMU notifier registrations for the same address range
    - N x hmm_range_fault() calls for the same page (KFD: 1x)
    - N x DMA mapping memory
    - N x invalidation + restore worker scheduling per CPU unmap event
    - N x GPU page table flush / TLB invalidation
    - Increased mmap_lock hold time, N callbacks serialize under it

compatibility issues:
    - Quiesce/resume scope mismatch: to integrate with KFD compute
      queues, the driver reuses kgd2kfd_quiesce_mm()/resume_mm()
      which have process level semantics. Under the per GPU 
      drm_gpusvm model, maybe there are some issues on sync. To properly
      integrate with KFD under the per SVM model, a compatibility or 
      new per VM level queue control APIs maybe need to introduced.

Migration challenges:

  - No global migration decision logic: each per GPU SVM
    instance maintains its own attribute tree independently. This
    allows conflicting settings (e.g., GPU0's SVM sets
    PREFERRED_LOC=GPU0 while GPU1's SVM sets PREFERRED_LOC=GPU1
    for the same address range) with no detection or resolution.
    A global attribute coordinator or a shared manager is needed to
    provide a unified global view for migration decisions

  - migrate_vma_setup broadcast: one GPU's migration triggers MMU
    notifier callbacks in ALL N-1 other drm_gpusvm instances,
    causing N-1 unnecessary restore workers to be scheduled. And 
    creates races between the initiating migration and the other
    instance's restore attempts.

  - No cross instance migration serialization: each per GPU
    drm_gpusvm instance has independent locking, so two GPUs'
    "decide -> migrate -> remap" sequences can interleave. While
    the kernel page lock prevents truly simultaneous migration of
    the same physical page, the losing side's retry (evict from
    other GPU's VRAM -> migrate back) triggers broadcast notifier
    invalidations and restore workers, compounding the ping pong
    problem above.

  - No VRAM to VRAM migration: drm_pagemap_migrate_to_devmem()
    hardcodes MIGRATE_VMA_SELECT_SYSTEM (drm_pagemap.c:328), meaning
    it only selects system memory pages for migration.

  - CPU fault reverse migration race: CPU page fault triggers
    migrate_to_ram while GPU instances are concurrently operating.
    Per GPU notifier_lock does not protect cross GPU operations.

We believe a strong, well designed solution at the framework level is
needed to properly address these problems, and we look forward to 
discussion and suggestions.

Honglei Huang (12):
  drm/amdgpu: add SVM UAPI definitions
  drm/amdgpu: add SVM data structures and header
  drm/amdgpu: add SVM attribute data structures
  drm/amdgpu: implement SVM attribute tree operations
  drm/amdgpu: implement SVM attribute set
  drm/amdgpu: add SVM range data structures
  drm/amdgpu: implement SVM range PTE flags and GPU mapping
  drm/amdgpu: implement SVM range notifier and invalidation
  drm/amdgpu: implement SVM range workers
  drm/amdgpu: implement SVM core initialization and fini
  drm/amdgpu: implement SVM ioctl and fault handler
  drm/amdgpu: wire up SVM build system and fault handler

 drivers/gpu/drm/amd/amdgpu/Kconfig            |   11 +
 drivers/gpu/drm/amd/amdgpu/Makefile           |   13 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c       |    2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.c       |  430 ++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.h       |  147 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.c  |  894 ++++++++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.h  |  110 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.c | 1196 +++++++++++++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.h |   76 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c        |   40 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h        |    4 +
 include/uapi/drm/amdgpu_drm.h                 |   39 +
 12 files changed, 2958 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_attr.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.h


base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
-- 
2.34.1


^ permalink raw reply	[flat|nested] 37+ messages in thread
end of thread, other threads:[~2026-04-28  7:00 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-20 12:07 [RFC V2 00/12] drm/amdgpu: SVM implementation based on drm_gpusvm Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions Honglei Huang
2026-04-20 12:15   ` Christian König
2026-04-20 13:30     ` Huang, Honglei1
2026-04-20 15:37       ` Christian König
2026-04-20 16:06         ` Matthew Brost
2026-04-20 16:28           ` Thomas Hellström
2026-04-20 18:07           ` Christian König
2026-04-21  5:08             ` Matthew Brost
2026-04-21  6:19               ` Christian König
2026-04-21  6:48                 ` Matthew Brost
2026-04-21  7:13                   ` Christian König
2026-04-21  9:52           ` Huang, Honglei1
2026-04-23  6:21         ` Huang, Honglei1
2026-04-23 10:39           ` Christian König
2026-04-23 11:06             ` Huang, Honglei1
2026-04-23 20:02               ` Matthew Brost
2026-04-24 10:20                 ` Huang, Honglei1
2026-04-24 10:12               ` Huang, Honglei1
2026-04-27 21:05                 ` Felix Kuehling
2026-04-28  2:24                   ` Huang, Honglei1
2026-04-28  6:49                   ` Christian König
2026-04-28  7:00                     ` Huang, Honglei1
2026-04-21  3:37     ` Kuehling, Felix
2026-04-21  6:39       ` Christian König
2026-04-20 12:07 ` [RFC/POC PATCH 02/12] drm/amdgpu: add SVM data structures and header Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 03/12] drm/amdgpu: add SVM attribute data structures Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 04/12] drm/amdgpu: implement SVM attribute tree operations Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 05/12] drm/amdgpu: implement SVM attribute set Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 06/12] drm/amdgpu: add SVM range data structures Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 07/12] drm/amdgpu: implement SVM range PTE flags and GPU mapping Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 08/12] drm/amdgpu: implement SVM range notifier and invalidation Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 09/12] drm/amdgpu: implement SVM range workers Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 10/12] drm/amdgpu: implement SVM core initialization and fini Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 11/12] drm/amdgpu: implement SVM ioctl and fault handler Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 12/12] drm/amdgpu: wire up SVM build system " Honglei Huang
  -- strict thread matches above, loose matches on Subject: below --
2026-03-17 11:29 [RFC/POC PATCH 00/12] POC SVM implementation in AMDGPU based on drm_gpusvm Honglei Huang
2026-03-17 11:29 ` [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions Honglei Huang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox