diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-12 05:09:17 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-12 11:08:21 -0400 |
| commit | 157eb059a2d65a2f0aafbccc6872c221710b86e1 (patch) | |
| tree | f885bd89cbfe331aea2ee5547460c0efacee3f95 /tools | |
| parent | 7b2a3723829f8bab0f5ea37196f81eefca6835b8 (diff) | |
| download | open-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.py | 15 |
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('-') |
