summaryrefslogtreecommitdiffstats
path: root/userspace/cuda/docs/07-version-upgrade-playbook.md
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-09 19:07:28 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-09 19:07:28 -0400
commit22238ebd3cfc6e568049cdd73773fb842ea41565 (patch)
tree1ff794f76be352163d68515c467dfa5181172072 /userspace/cuda/docs/07-version-upgrade-playbook.md
parentc126d3f9a6a5ff4a34b14bbaed15bcbb33854467 (diff)
downloadopen-iov-22238ebd3cfc6e568049cdd73773fb842ea41565.tar.gz
open-iov-22238ebd3cfc6e568049cdd73773fb842ea41565.zip
vgsp-sema: forwarding owns the release when a candidate is captured (ISSUE-0002)
r65 showed the operand-hold release gate must not run before the forwarding gate: for a GR launch push whose software operand was pending, the operand hold applied the launch-completion release as soon as the software op ran, so the client passed the launch-completion wait while the physical launch was still in flight; when the physical launch later timed out (qmd_rel stuck at 5, want 6) the client read zeros (MAIL bad). Order the release sites fwd-first: when a forwarding candidate is captured, drop any operand-hold record for the entry (the fwd record set carries the same release) and record into the fwd set so the hardware completion (or its bounded fallback) is the single delivery edge. The operand hold keeps owning the release only when no candidate is captured, exactly as r62 intended.
Diffstat (limited to 'userspace/cuda/docs/07-version-upgrade-playbook.md')
0 files changed, 0 insertions, 0 deletions