open-iov.git/tools/guest-diag/semfix_uvmt.py, branch cs-share

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

2026-10-02T19:13:06+00:00

- 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-: 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).

guest-diag: reset per-client pin state when a new client pid appears

2026-09-30T14:06:20+00:00

A new CUDA client allocates fresh channel pools at the same GPU VAs; the watcher kept the previous client's sem kptrs and seen-pin marks, so it pinned the previous (freed) pool pages and the new client's release writes went to dead memory. Clear the learned sems/marks on each pid change.

guest-diag: pushbuffer pin survives PTI holes (full-range scan + bounded retries until complete)

2026-09-30T09:28:13+00:00

guest-diag: semfix counter-pin retry backoff + shorter exec timeout (stops guest-agent starvation)

2026-09-29T22:08:38+00:00

guest-diag: stream uvbp pushbuffer kptrs for immediate pinning

2026-09-29T21:27:48+00:00

The first CE channel's push-buffer was only pinned ~1 minute after the client's failure: uvbp fired at t+4s but semfix's trace read (guest agent, every 5 loops) picked it up at t+70s, so the tracker wait for value 3 spun for 16 s. The guest scanner now emits '#pb 0x' from the uvbp trace lines as soon as they appear; the host mirrors them into the sem stream and semfix resolves/pins the push-buffer through the UVM chain on the next loop (sub-second).

sema-svc: persist GR counter slot per channel; stable slot layout; bulk pin queue 4k

2026-09-29T20:14:12+00:00

- counter_pa autoreg result is written back to the channel table so later passes cannot re-target a different slot when the live GR count changes during teardown; re-registration of the same channel preserves the slot. - counter slot layout uses the max GR count ever seen in the generation instead of the shrinking live count. - sema_map_add queue 64 -> 4096 entries so a full-window pin burst drains without ENOSPC retries. - pin_gr_stream: one batched sudo pass per flush (was one process per run, ~4 s for 400 runs), retrying only queue-rejected runs. - semfix_uvmt: SEMFIX_SKIP_PB=1 skips the blocking push-buffer chain walk when the vsock window stream already supplies those pages.

sema-svc: apply releases before push memsets; poller: bypass read cache

2026-09-29T19:34:18+00:00

guest-diag: stream uvmt sems over vsock (no guest-agent race); dump channel last release VA; larger push log budget

2026-09-29T19:24:31+00:00

sema-svc: never apply swept-page releases with no live channel (guest boot corruption); tooling guards

2026-09-29T19:19:34+00:00

sema-svc: apply decoded releases to registered counter slots; single-QMP semfix+uvmt watcher

2026-09-29T19:16:39+00:00