kernel: GR context-promote bisection modes 4-17 and server-managed-ctxbuf registry variant; complete vgsp rename; docs/tooling refresh

- gsp_phys_booter: GR promote bisection modes 4-17 (two-phase zero-field VA,
  batched entries, hVirtMemory, bare VA, KMD SKIP_CTXBUFFER_ALLOC channel,
  old-interface GPU_INITIALIZE_CTX, FBMEM context buffer, UVM-faithful PA-only,
  PATCH/PM auxiliary promotes, server-managed no-promote path); PATCH/PM
  geometry queries and buffers; pre-boot SET_REGISTRY profile selection
- gsp_phys_gpu: gsp_phys_rmcall_gr_promote clamp 0..17 and gsp_phys_srv_ctxbuf
  parameter; registry image variant with RMSetClientRMAllocatedCtxBuffer=0
- vgsp rename across kernel, scripts, tools and docs (module vgsp.ko,
  /sys/kernel/debug/vgsp/, vgsp-<subsystem>: log prefixes)
- risc-v-gsp-rm-debugger user-facing rename and docs/CI refresh; guest-diag
  tool updates; README/SBOM/install/Makefile sync

Live status: CE ladder and P6 guest-copy forwarding green; GR engine context
commit still open (all promote shapes accepted or cleanly refused; the channel
stays CTXNOTVALID) - see Handoff-vGPU-IO.md Addendum 21 (local).

1 files changed, 4 insertions, 4 deletions

diff --git a/debug/risc-v-gsp-rm-vm/RISC-V-GSP-RM-DEBUGGER-ROADMAP.md b/debug/risc-v-gsp-rm-vm/RISC-V-GSP-RM-DEBUGGER-ROADMAP.md
index 88183ea..a7a8227 100644
--- a/debug/risc-v-gsp-rm-vm/RISC-V-GSP-RM-DEBUGGER-ROADMAP.md
+++ b/debug/risc-v-gsp-rm-vm/RISC-V-GSP-RM-DEBUGGER-ROADMAP.md
@@ -12,7 +12,7 @@ Open-IOV's hardest long-term problem is not writing the emulation once — it is
 **surviving adversarial firmware change**. NVIDIA ships new GSP images, new
 device pairings and new architectures on independent schedules, and the
 firmware is deliberately opaque (stripped, signed, hardware-coupled, with
-non-recoverable boot states). To keep `open-iov-vfio` accurate across that
+non-recoverable boot states). To keep `vgsp` accurate across that
 churn, the project needs a toolchain that can:
 
 1. **Run** firmware off-hardware, safely and repeatably.
@@ -22,7 +22,7 @@ churn, the project needs a toolchain that can:
 4. **Compare** — hardware vs VFIO vs simulation, old vs new firmware, with a
    metric contract instead of anecdotes.
 5. **Reimplement** — turn observed behaviour into reviewed code in
-   `open-iov-vfio` with evidence attached.
+   `vgsp` with evidence attached.
 
 risc-v-gsp-rm-debugger is the vehicle for that program. It is explicitly a **development
 environment**, never a shipped component.
@@ -226,7 +226,7 @@ reimplement quickly.
 Observe what each service reads/writes (watchpoints, TCG trace) and infer
 capabilities (which objects, ranges, controls it touches); compare with the
 declared/emulated capability model; surface least-privilege and security
-findings for `open-iov-vfio`.
+findings for `vgsp`.
 
 ### H4.3 Mutation and fuzzing
 Feed malformed construction/control traffic into re-hosted or simulated
@@ -247,7 +247,7 @@ The canonical loop for any behaviour:
 1. Observe on hardware/VFIO (reference capture).
 2. Observe in risc-v-gsp-rm-debugger (simulator, replayable).
 3. `compare` + metric table M1–M6 (docs/06-ACCURACY.md).
-4. Implement in `open-iov-vfio` with the session directories attached as
+4. Implement in `vgsp` with the session directories attached as
    evidence.
 5. Re-run the same stimulus; the metric table must improve or stay equal.
 This loop becomes a scripted harness ("consensus harness") so every change