summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-12 05:09:17 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-12 11:08:21 -0400
commit157eb059a2d65a2f0aafbccc6872c221710b86e1 (patch)
treef885bd89cbfe331aea2ee5547460c0efacee3f95 /tools
parent7b2a3723829f8bab0f5ea37196f81eefca6835b8 (diff)
downloadopen-iov-157eb059a2d65a2f0aafbccc6872c221710b86e1.tar.gz
open-iov-157eb059a2d65a2f0aafbccc6872c221710b86e1.zip
vgsp-sema: re-arm ring/push-buffer discovery latches on channel registration; scanner streams anonymous high-VA buffers
Second-client wedge fix: a new GSP session re-registers the same channel handles/ranks, but the per-rank one-shot ring/push-buffer discovery latches stayed set from the previous session, so the new session's ring was never re-autopinned (ring_auto=0 pb=0/0, nomap growing) and the guest spun in its channel-creation wait. svc_chan_rearm_rank() clears the latches on every channel registration; all post-fix cycles launch the second client. Scanner: guest_pin_stream.py now streams the client's anonymous high-VA mappings (cudaMalloc buffers were skipped by the old len(parts)<6 check), so the host can learn their pages. Diagnostics: PT-window lines, per-window first words, post-OK qmdwin w48..59. Remaining: the fill-time svc_ipin_lookup miss for the second client's a/b/c pins (they exist in the pin log but are not seen at fill time) - next session.
Diffstat (limited to 'tools')
-rw-r--r--tools/guest-diag/guest_pin_stream.py15
1 files changed, 12 insertions, 3 deletions
diff --git a/tools/guest-diag/guest_pin_stream.py b/tools/guest-diag/guest_pin_stream.py
index 04aba73..739aeca 100644
--- a/tools/guest-diag/guest_pin_stream.py
+++ b/tools/guest-diag/guest_pin_stream.py
@@ -778,10 +778,19 @@ def scan_vmas(fd, pid, out):
try:
for line in maps:
parts = line.split()
- if len(parts) < 6:
+ if len(parts) < 5:
continue
- path = parts[5]
- if not any(p in path for p in VMA_PATHS):
+ # Anonymous mappings (no path field) are the client's UVM sysmem
+ # buffers when the driver maps them without a /dev/zero backing:
+ # the second client's cudaMalloc'd data buffers show up exactly
+ # like that (e.g. 75d7b0000000-75d7b0021000 rw-p 00000000 00:00 0)
+ # and were skipped by the old len<6 check, so their pages never
+ # reached the host and the forwarded launch could not resolve
+ # them (all-zero results for the second client). Accept them at
+ # the high-VA range; the VMA_LO bound and the pagemap present/PFN
+ # filters keep the set to real GPU mappings.
+ path = parts[5] if len(parts) >= 6 else ''
+ if path and not any(p in path for p in VMA_PATHS):
continue
try:
a, b = parts[0].split('-')