diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-12 11:35:32 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-12 11:35:32 -0400 |
| commit | 70a80cc733f94b7bd27ec2e61173e39221c22324 (patch) | |
| tree | df268cb4f33b7826d865b8ee09038240354d4541 /wiki/open-iov.org/index.php?title=File:Figure_0-_Approches_to_GPU_Virtualization..png&action=edit.html | |
| parent | 9e23d0f454383393a26f2b6d728ca7e8bf427f01 (diff) | |
| download | open-iov-70a80cc733f94b7bd27ec2e61173e39221c22324.tar.gz open-iov-70a80cc733f94b7bd27ec2e61173e39221c22324.zip | |
vgsp-sema: resolve the CE push buffer from the kernel chain (second-client stall)
The second CUDA client's GPFIFO entries in the CE push-buffer window
(0x120000000) had no injected pin: that window is never mapped into the
client's pagemap, so the scanner's window scan cannot see it, and its
only supplier - the one-shot uvbp kprobe event - is raced by two trace
clears (the scanner's pid-switch clear and semfix's trace-tail clear).
When the event loses the race the entry reads fall back to the ~250 ms
content rescue, which is the second-client stall and the same
resolution-miss class as the ISSUE-0001 lottery.
The guest scanner now walks channel->pool->manager->pushbuffer->rm_mem
in kernel memory with kcore and pins the push-buffer pages directly (no
trace event to lose), and the trace reader's dedup marks reset on a
client switch so a reused kptr cannot suppress the new client's #pb.
Boot evidence (r112): rescue reject ipin=0 for va_page=0x120023000,
rescue scans 175 ms - 1 s each, want incrementing to 39. Smoke test of
this fix on the stalled VM: 478 pin runs (~7955 pages) streamed within
seconds, first va=0x120000000 -> pa=0x108090000. A bounded kernel log
now prints the first CE push-buffer pins of each session.
Diffstat (limited to 'wiki/open-iov.org/index.php?title=File:Figure_0-_Approches_to_GPU_Virtualization..png&action=edit.html')
0 files changed, 0 insertions, 0 deletions
