<feed xmlns='http://www.w3.org/2005/Atom'>
<title>open-iov.git/tools/guest-diag/guest_pmap_win.py, branch gr-forwarding</title>
<subtitle>Open-IOV vGPU-IO: host-side GSP emulation for unmodified NVIDIA guest drivers
</subtitle>
<id>https://git.vgpu.io/open-iov.git/atom?h=gr-forwarding</id>
<link rel='self' href='https://git.vgpu.io/open-iov.git/atom?h=gr-forwarding'/>
<link rel='alternate' type='text/html' href='https://git.vgpu.io/open-iov.git/'/>
<updated>2026-09-29T18:47:17+00:00</updated>
<entry>
<title>guest-diag: cheaper trace read, optional push sampler, bigger pagemap batches</title>
<updated>2026-09-29T18:47:17+00:00</updated>
<author>
<name>Arthur Hanson Rasmusson</name>
<email>arthur@vgpu.io</email>
</author>
<published>2026-09-29T18:47:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.vgpu.io/open-iov.git/commit/?id=fdeb1d4ba62283210dc259141da4da024bd1cc77'/>
<id>urn:sha1:fdeb1d4ba62283210dc259141da4da024bd1cc77</id>
<content type='text'>
Under load the semfix poll grepped the whole (growing) trace file and the
track_waits push block spawned three guest processes per sample, both of
which slowed the pin path into the client's failure window. The trace read
now tails 128 KB; track_waits.sh gates the push dump behind PUSH=0; the
pagemap helper reads 32 KB chunks.
</content>
</entry>
<entry>
<title>kernel: grace window for untranslatable GR entries; tools: coalesce window pin output</title>
<updated>2026-09-29T18:41:14+00:00</updated>
<author>
<name>Arthur Hanson Rasmusson</name>
<email>arthur@vgpu.io</email>
</author>
<published>2026-09-29T18:41:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.vgpu.io/open-iov.git/commit/?id=a83a42df71c235c5f9f8eaeb3b62053a75fe30c7'/>
<id>urn:sha1:a83a42df71c235c5f9f8eaeb3b62053a75fe30c7</id>
<content type='text'>
The first GR window pin landed ~2 s after the pump consumed the freshly
created channels' GPFIFO entries on the first failed read, so the pushes
(and the tracking-semaphore releases they carry) were lost. GR entries with
an unresolvable push page now stay pending for sema_gr_grace_ms (default
8 s) before the stale-entry consume; a pin landing in that window makes the
entry readable and it executes normally. The completion counter is still
published from put at the end of every pass, so the client's counter wait
is not delayed.

guest_pmap_win.py coalesces contiguous VA+PA pages into run lines, so a
15k-page window transfers as ~200 lines instead of ~15k and the pin batch
lands within a second of the pages appearing.
</content>
</entry>
<entry>
<title>tools: pin GR push-buffer window from guest pagemap per boot; widen injected-pin table</title>
<updated>2026-09-29T18:38:44+00:00</updated>
<author>
<name>Arthur Hanson Rasmusson</name>
<email>arthur@vgpu.io</email>
</author>
<published>2026-09-29T18:38:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.vgpu.io/open-iov.git/commit/?id=ca944b45ba35f3c0dc63fa9f722067af13e97ab4'/>
<id>urn:sha1:ca944b45ba35f3c0dc63fa9f722067af13e97ab4</id>
<content type='text'>
The GR channel GPFIFO entries point at pushes in the client GPU VA window
(observed 0x200400000 + stride, one allocation per channel) and the pump
cannot read them: pushes_nomap grows and the tracking-semaphore releases
they carry never land. The pushes are sysmem pages mapped into the client
process, so /proc/&lt;pid&gt;/pagemap in the guest gives the GPA.

New guest helper guest_pmap_win.py batch-reads the pagemap of a VA range
(512 entries per pread). New host tool pin_gr_window.py rescans the window
on an interval, follows cdt pid changes, and injects VA-&gt;PA runs through
sema_map_add (same mechanism as the counters and the CE pushbuffer pins).
The injected-pin table grows 8k -&gt; 32k slots so the CE pushbuffer (4096)
plus the GR window pages fit without drops.
</content>
</entry>
</feed>
