open-iov.git/tools/guest-diag/guest_pin_stream.py, branch m31

vgsp: host CUDA bridge + sema release recovery; greeneye simulator wave

2026-10-03T18:05:38+00:00

- kernel: gsp_cuda_bridge (QMD launch capture, debugfs job/out/done, param+output resolution cached from inline writes), sema drain fixes (never hold/starve a channel), GR ring autopin + counter autoreg, per-page push reads, counter-derive gate; module builds clean - tools/cuda-bridge: CUDA driver-API daemon executing mail/vadd kernels on the physical GPU, CUBB2/CBD2 v2 protocol, layout check + self-tests - tools/guest-diag + tools/cuda-ab: scanner/pin fixes, victory push-only mode - debug/risc-v-gsp-rm-vm: Phase S simulator wave (GSP device model, boot ladder, triage/re-demo harnesses, docs 30-41), GPGPU-sim scaffolding - STATE-CURRENT/docs updates

guest-diag: stream the client's high-VA UVM sysmem pages as pins

2026-09-30T16:54:15+00:00

The DtoH staging buffer lives in the client's high-VA /dev/zero|nvidia mappings (e.g. devptr+0x3c00100), outside the scanner's fixed CE/GR windows; only the host's pagemap read can see it. The guest scanner now walks those VMAs and streams their present pages so the module pins them. run_cycle.sh learns the sema_dbg master switch (auto-on when any watch knob is set).

guest-diag: pin scanner matches va* clients too (static-cudart vectorAdd)

2026-09-30T13:43:03+00:00

guest-diag: pin scanner matches cdt* so the copy-path test binary is tracked

2026-09-30T10:25:03+00:00

The GR-window pin scanner matched comm=="cdt" exactly, so runs using the cuda_drv_test2 binary (comm "cdt2") never streamed their mappings: the GR push pages stayed unresolvable and the client stalled in context creation. Match the cdt prefix instead.

gsprm: reply-latency logging + param dump cap; guest-diag: CDT_PAUSE, watcher reaping, wider CE stream window

2026-09-30T04:06:42+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).

guest-diag: pin the CE push-buffer window too

2026-09-29T21:08:09+00:00

The failing wait (uvtw) is uvm_tracker_wait_for_entry for value 3 on a CE channel whose tracking sem stayed at payload 1 for 14 s: its pushes' release values 2..3 were never applied because the CE push-buffer pages (0x120000000 + 0x100000*rank) are outside the GR window and were only found by the content sweep, late and often wrong (false=3065). Scan both windows in the guest so the host gets guest-truth translations for the CE pushes as well.

guest-diag: non-blocking trace tail + 100ms scan loop + raw counter-page dump

2026-09-29T20:51:57+00:00

- the trace tail (subprocess + 256KB read) ran inside the scan loop and blocked it for seconds exactly when the client's GR window appeared; moved to a background thread whose queue the loop drains. - scan interval 250ms -> 100ms. - track_waits sampler also dumps 512 raw bytes at page+0xe00 each sample: the per-slot reads disagreed with the bulk dump within one sample because host writes land between the two, and the raw dump is the only trustworthy view of the slot layout.

sema-svc: bounded diagnostics for GR counter writes; scanner guarantees counter-page delta

2026-09-29T20:32:03+00:00

- rel-apply/publish now log the first 32/48 outcomes (written, skipped with current value, no slot, read failure) so the live counter page can be matched against host writes. - guest pin scanner logs the counter page's pagemap state each loop and adds it to the delta set explicitly, so the page is pinned the moment it is mapped even if the window scan misses it.

guest-diag: scan 512KB per 2MB region and start window at 0x200000000 (cover GR GPFIFO rings)

2026-09-29T19:42:58+00:00