svm_range_add(9)

📦 version 7.3.1, in nixpkgs unstable

💅 svm_range_add(9) — like, the whole glow-up

okay bestie so this is a page straight out of the Kernel API Manual, and it's about svm_range_add(9) — adding an svm range and handling overlap. yes it's kernel-level, yes it's a lot, but we're gonna get through it together 🫶

✨ NAME ✨

svm_range_add — add svm range and handle overlap 💫

🌸 SYNOPSIS 🌸

int svm_range_add (struct kfd_process *p , uint64_t start , uint64_t
size , uint32_t nattr , struct kfd_ioctl_svm_attribute *attrs , struct
list_head *update_list , struct list_head *insert_list , struct
list_head *remove_list , struct list_head *remap_list );

🎀 ARGUMENTS 🎀

  • p — the range gets added to this process's svms, it's giving very "main character process" energy 👑
  • start — page size aligned, no cap 📏
  • size — page size aligned too, keep that energy consistent ✨
  • nattr — literally just the number of attributes 🔢
  • attrs — an array of attributes, the whole squad of them 🧚
  • update_list — output, the ranges that need to be validated and have their GPU mapping updated 🔥
  • insert_list — output, the ranges that need to be inserted into svms 🌸
  • remove_list — output, the ranges that got replaced and need to be removed from svms 💀
  • remap_list — output, remaps the unaligned svm ranges 🦋

💖 DESCRIPTION 💖

so what it does: it checks if the virtual address range has overlap with any existing ranges, splits the partly overlapping ranges, and adds new ranges in the gaps. iconic behaviour honestly ✨

the important part, and i mean the important part: all changes should be applied to the range_list and interval tree transactionally. if any range split or allocation fails, the entire update fails — like, the whole thing, no partial slay 😭. that's why any existing overlapping svm_ranges are cloned and the original svm_ranges are left unchanged. we do not touch the originals, periodt 💅

  • if the transaction succeeds, the caller can update and insert clones and new ranges, then free the originals 🎉
  • otherwise the caller can free the clones and new ranges, while the old svm_ranges remain unchanged 🫶
bestie the whole point is: originals stay safe until the transaction says it's a go. do not skip the clone step, i'm begging 🙈

🔥 CONTEXT 🔥

Process context — and the caller must hold svms->lock. no lock, no entry, iykyk 🔒

⭐ RETURN ⭐

0 — OK ✨, otherwise an error code 😭

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/amd/amdkfd/kfd_svm.c — go read it, it's giving lore 📚

and that's the whole page, bestie 🎀 tysm for reading, mwah 💜

sign-off time: this came from ./drivers/gpu/drm/amd/amdkfd, dated October 2026, page svm_range_add(9) — stan the kernel docs fr fr 🌸
📦 where this page comes from