open-iov.git/tools/guest-diag/memprobe.py, branch m33Open-IOV vGPU-IO: host-side GSP emulation for unmodified NVIDIA guest drivers
https://git.vgpu.io/open-iov.git/atom?h=m332026-09-28T13:09:13+00:00sem: run GR channels - accept CE methods on subchannel 0, discover GR rings2026-09-28T13:09:13+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-09-28T13:09:13+00:00urn:sha1:448d1d9a6f9168006910a79e177d4bed331bacc6
- The CE semaphore/memset method groups also arrive on subchannel 0 (CUDA's
push library binds the copy class on compute channels to carry the
work-submission releases), so the stream decoder accepts both 0 and 4.
- GR (compute) channel rings live in the same video-memory allocation as the
CE rings, 0x3000 bytes per channel after them: ring (0x2000) at
ce_end + 0x3000*rank, USERD at +0x2000. Discover and pin them once the CE
ranks are known; verified against ring entry 0 (1 MB aligned push VA in
the client window, sane length) and the USERD's put/get, so a layout
change costs a failed pin, not a wrong one. Gated by sema_gr_rings
(default on).
- memprobe: require the sem-VA triple in the sem-object scanner (a bare
qword in the window matches thousands of unrelated pointers once the
ring/pushbuffer windows are part of the range).
Live evidence: ring entries read through the guest's /proc/pid/mem decode to
the GR channels' first pushes; pinning the ring (fb 0x140000+0x3000*rank),
USERD (ring+0x2000) and first-push pages made all 20 GR channels execute
their entry 0 for the first time (get=1 sub=1).
sema-svc: apply releases promptly and decode compute-push releases2026-09-28T11:34:34+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-09-28T11:34:34+00:00urn:sha1:17e1f522e4e9e04d13c4ca9495a2f4f1bdc58c36
The content sweep now:
- decodes a release whose method stream continues with any INC_METHOD,
not only the CE LAUNCH_DMA group, so the releases at the head of a
compute/GR channel's first push are applied too;
- remembers releases whose target VA had no translation (deferred list)
and retries them every service pass, so a VA->PA injection lands them
immediately instead of after the next full sweep;
- re-arms the fast sliced sweep for a few seconds after an injection;
- treats a channel whose USERD/ring cannot be resolved as stalled, so the
sweep keeps looking for the releases its unreadable pushes carry.
tools: add per-cdt client-pin helper (sem pages + /dev/nvidia0 windows),
sem-page scanner and memprobe fixes (short-read guard, --brief).
Live-verified: injecting a client sem page applied 12 deferred releases
within a second; the service kept applying (89 -> 202) while cdt ran.
kernel: add a channel-table dump param; tools: fix memprobe --max parsing2026-09-26T06:46:41+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-09-26T06:46:41+00:00urn:sha1:3c3d0637a57a92d6ae4f1b934ba3282b2366160fgsp_sema_service: add content rescue for unmapped push-buffer pool VAs2026-09-25T05:48:37+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-09-25T05:48:37+00:00urn:sha1:93769b1e19b4ce2cf1738d72e600adc5a9ef315b
- Add expected_sem_payload tracking to svc_channel for CE channels
- Implement svc_rescue_push_page() to scan guest RAM for push with
expected semaphore release when VA translation fails
- Add svc_init_expected_payload() to initialize expected payload from pool
- Add rate-limited logging of distinct stalled VAs (svc_log_stalled_va)
- Advance expected_sem_payload on successful push decode
- Pushes SEMA_MAP_MAX to 65536, SVC_PIN_SLOTS to 32768 for scale