GGTT NODES SHIFTING DURING VF POST-MIGRATION RECOVERY(9)

💜 GGTT nodes shifting during VF post-migration recovery(9) 💜

okay bestie, welcome to the Kernel API Manual, section 9 — yes this is a kernel-doc page, yes it's about GPU address space, and yes it's gonna be cute anyway 🎀

---

🌸 NAME 🌸

GGTT nodes shifting during VF post-migration recovery — the very first fixup we do to the VF KMD structures when we're recovering a VF after migration 💫

---

✨ DESCRIPTION ✨

so. picture this: your VF just migrated. everything's back, everyone's fine, but the first fixup applied to the VF KMD structures as part of post-migration recovery is shifting nodes within the xe_ggtt instance 🫶 The nodes literally get moved out of the range that was previously assigned to this VF, and dropped into the newly provisioned area. that's the whole bit. iconic, honestly.

below is a GGTT layout of an example VF, with a certain address range assigned to said VF, and inaccessible areas above and below 👑

0
4GiB |<--------------------------- Total GGTT size
----------------------------->| WOPCM
GUC_TOP |<-------------- Area mappable by xe_ggtt instance
---------------->|

then we get the big art box (in the original it's one giant ┌───┐ deal — we're keeping the vibes, not the border spam) 💅

\\h'|2232u'/////////////////////////////////  VF mem   //////////////////////              \.TE


Hardware enforced access rules before migration:


|<------- inaccessible for VF ------->|<VF owned>|<-- inaccessible for VF ->|

After the migration, the GGTT area assigned to the VF might have shifted — either to lower or to higher address 😭 but we expect the total size and extra areas to be identical, as migration can only happen between matching platforms. no cap. same platform, same shape.

below is an example of GGTT layout of the VF after migration. Content of the GGTT for VF has been moved to a new area, and we receive its address from GuC 🧚

\\h'|2232u'//////////////////////             VF mem   /////////////////////////////////   \.TE


Hardware enforced access rules after migration:


|<- inaccessible for VF -->|<VF owned>|<------- inaccessible for VF ------->|

so the VF has a new slice of GGTT assigned, and during the migration process the memory content was copied to that new area. but — and this is the plot twist 🫢 — the xe_ggtt nodes are still tracking allocations using the old addresses. rude. so the nodes within the VF owned area have to be shifted, and the start offset for GGTT adjusted. main character energy: the nodes get relocated, periodt.

👑 tiny caveat, bestie, don't skip it: due to use of GPU profiles, we do not expect the old and new GGTT areas to overlap; but our node shifting will fix addresses properly regardless. so like, it's fine either way 💖

---

🔗 SEE ALSO 🔗

• xe_tile_sriov_vf_ggtt_base_store(9) — go read it, it lives over in tile_sriov_vf.c 🦋

---

that's the page, bestie 🥳 go shift some nodes. ily 💜

🌸 sign-off szn 🌸 — this lil beauty comes from ./drivers/gpu/drm/xe, dated October 2026 🎀 (and the header calls it GGTT nodes ...ion recovery(9), but we both know it's the same baddie ✨)