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, 5 insertions, 5 deletions

diff --git a/docs/02-getting-started/01-install-and-first-run.md b/docs/02-getting-started/01-install-and-first-run.md
index 9ae81c2..7bc12bc 100644
--- a/docs/02-getting-started/01-install-and-first-run.md
+++ b/docs/02-getting-started/01-install-and-first-run.md
@@ -55,7 +55,7 @@ make userspace
 ```
 
 **Build-order matters.** The NVIDIA modules resolve symbols that
-`open-iov-vfio.ko` exports; building them in the wrong order produces
+`vgsp.ko` exports; building them in the wrong order produces
 `Unknown symbol` failures at load time. See
 [`../03-architecture/06-host-module-and-hybrid-model.md`](../03-architecture/06-host-module-and-hybrid-model.md).
 
@@ -69,7 +69,7 @@ make userspace
 ```
 
 **The `nvidia` (OpenRM) stage is optional.** It is needed only when the host
-must run NVIDIA's OpenRM modules built against the symbols `open-iov-vfio.ko`
+must run NVIDIA's OpenRM modules built against the symbols `vgsp.ko`
 exports — that is, the native vGPU-management/RM-callback workflows. The
 QEMU/emulated path uses the distribution driver that already manages the
 physical GPU; `load-stack` skips the OpenRM submodule when a distribution
@@ -167,7 +167,7 @@ by hand while a VM holds the mdev.
 ## 8. Watching the emulation work
 
 Every meaningful decision the emulation makes is visible in `dmesg` with the
-prefix **`gsp-resman-vfio:`** (module logs) and the per-RPC traces. Handy:
+prefix **`vgsp:`** (module logs) and the per-RPC traces. Handy:
 
 ```bash
 sudo dmesg -w | grep -iE 'gsp-resman-vfio|gsp_|rpc'      # live
@@ -181,7 +181,7 @@ Developer debug knobs (module parameters) are documented in
 
 | Symptom | Start here |
 |---|---|
-| Module will not load | `dmesg`, `modinfo open-iov-vfio.ko`, stale module state → `cleanup-crash` |
+| Module will not load | `dmesg`, `modinfo vgsp.ko`, stale module state → `cleanup-crash` |
 | No mdev type for your GPU | [hardware matrix](../06-portability/hardware-software-matrix.md) |
 | Guest sees wrong PCIe link speed/width | root-port attachment + config-space mirror (debugging doc) |
 | `nvidia.ko` probe fails in guest | guest dmesg + `lspci -vvv` + [driver lifecycle field guide](../03-architecture/07-driver-lifecycle-field-guide.md) |
@@ -192,7 +192,7 @@ Developer debug knobs (module parameters) are documented in
 
 ```bash
 ./scripts/stack_manager.sh unload
-sudo rmmod open_iov_vfio nvidia nvidia_modeset nvidia_uvm  # if present
+sudo rmmod vgsp nvidia nvidia_modeset nvidia_uvm  # if present
 ```
 
 The project never modifies your host driver's files; removing the Open-IOV