<feed xmlns='http://www.w3.org/2005/Atom'>
<title>open-iov.git/tools/cuda-ab/ab.sh, branch golden-replay</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=golden-replay</id>
<link rel='self' href='https://git.vgpu.io/open-iov.git/atom?h=golden-replay'/>
<link rel='alternate' type='text/html' href='https://git.vgpu.io/open-iov.git/'/>
<updated>2026-10-03T18:05:38+00:00</updated>
<entry>
<title>vgsp: host CUDA bridge + sema release recovery; greeneye simulator wave</title>
<updated>2026-10-03T18:05:38+00:00</updated>
<author>
<name>Arthur Hanson Rasmusson</name>
<email>arthur@vgpu.io</email>
</author>
<published>2026-10-03T18:05:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.vgpu.io/open-iov.git/commit/?id=cc79b478843f0230fe6aa8ecd822de7ba71c891e'/>
<id>urn:sha1:cc79b478843f0230fe6aa8ecd822de7ba71c891e</id>
<content type='text'>
- 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
</content>
</entry>
<entry>
<title>kernel: execute pushed CE work (PTE memsets, copies) and track semaphores</title>
<updated>2026-09-23T10:31:44+00:00</updated>
<author>
<name>Arthur Hanson Rasmusson</name>
<email>arthur@vgpu.io</email>
</author>
<published>2026-09-23T10:31:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.vgpu.io/open-iov.git/commit/?id=7fdbe8713c8cf746cd1a15e93e0de39d333905c7'/>
<id>urn:sha1:7fdbe8713c8cf746cd1a15e93e0de39d333905c7</id>
<content type='text'>
The progress service now decodes push buffers as method streams and performs
the work the driver pushes, not just the tracking semaphore:

- C5B5 method decoder: SET_REMAP_CONST_A/B + COMPONENTS + OFFSET_OUT +
  LINE_LENGTH_IN + LAUNCH_DMA = memset (into vidmem or guest RAM);
  OFFSET_IN + OFFSET_OUT + LAUNCH_DMA = copy; SET_SEMAPHORE_A/B/PAYLOAD +
  LAUNCH_DMA = release. Contiguous method runs (count 2/4) are applied in
  full - OFFSET_IN/OUT arrive as one run.
- Pushes span page boundaries, so pages are decoded as method streams
  without a start marker. Collected operations execute only when the
  push's release is reached and still pending (payload ahead of the
  semaphore), so recycled buffers replaying old pushes are skipped and
  their stale memsets cannot overwrite newer state.
- VA-&gt;PA map is first-wins: stale copies of freed allocations and
  unrelated adjacent u64 pairs produced bogus entries that hijacked a
  good mapping and sent semaphore writes to the wrong page.
- dump_guest module parameter (hex dump of guest PA, kthread via
  completion; kthread_stop before the thread runs loses the work).

With this the guest no longer stalls in uvm_tracker_wait and no longer
oopses in the UVM path; the failure moved to a userspace segfault inside
libcuda (NULL-0x38) after the driver's page allocations.

Also add tools/cuda-ab: run one deterministic CUDA workload on the host
(bare metal oracle) and in the guest, then compare the stable result
lines. The binary links the CUDA runtime statically so the guest only
needs the driver's libcuda.so.
</content>
</entry>
</feed>
