diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-14 13:40:54 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-14 13:40:54 -0400 |
| commit | 6b090f70816f60a1a98fcf5889a3275177e8c132 (patch) | |
| tree | 905c559405ba27027a2e690eb994dc5591db0bae /wiki/GPU_Driver_Internals.md | |
| parent | 074f493c8bf51e487f5cdff30adbcbc65ad7b79b (diff) | |
| download | open-iov-6b090f70816f60a1a98fcf5889a3275177e8c132.tar.gz open-iov-6b090f70816f60a1a98fcf5889a3275177e8c132.zip | |
vgsp-gr: bounded fresh-entry retry for a forwarded launch whose QMD did not run
A green forwarded launch completes in ~170-195 ms, but an intermittent
subset times out with qmd_rel stuck at 5 (cold context save/unload, or an
entry the PBDMA never fetched). The existing recovery only replays the
schedule verbs, which cannot help once the entry was fetched or never
latched, so the client fell back to the software release and read
stale/zero results.
On a timeout, after the schedule re-arm, re-publish a FRESH ring entry with
the same PB/QMD content and re-issue schedule+doorbell, up to
GSP_PHYS_RMCALL_GR_ATTEMPTS (3) with a GSP_PHYS_RMCALL_GR_RETRY_MS (2000 ms)
poll. Safe against double execution: the timeout path never copies the
result out to the guest, so a timed-out attempt did not reach the client -
only the eventually-successful attempt is visible. New counter
gsp_phys_gr_retries and a 'retry N/M fresh ring entry' log line.
Diffstat (limited to 'wiki/GPU_Driver_Internals.md')
0 files changed, 0 insertions, 0 deletions
