diff options
Diffstat (limited to 'STATE-CURRENT.md')
| -rw-r--r-- | STATE-CURRENT.md | 32 |
1 files changed, 19 insertions, 13 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 0a5e30e..9543100 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-09-30 00:40.** This is a dated public status page, not live +> **Snapshot: 2026-09-30 05:05.** This is a dated public status page, not live > state; it is refreshed on every progress check. Live working notes are > maintained outside this repository; the public known-knowns/unknowns document > is authoritative here: @@ -28,7 +28,7 @@ meant to execute on the physical GPU. | Stock 570.144 guest driver probe / `RmInitAdapter` | ✅ | | `nvidia-smi -L` enumerates the emulated TU104 | ✅ | | CUDA userspace: `cuInit`, `cuDeviceGetCount`, `cuDeviceGet` | ✅ | -| `cuCtxCreate` returns | ⏳ **frontier** | +| `cuCtxCreate` returns | ⏳ **frontier** - the previously fatal check now passes; the final result is being captured | | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ❌ not reached | | Full `nvidia-smi` output | ❌ (faults on the CUDA path) | | CUDA kernel execution (`vectorAdd`) | ❌ not started (forwarding layer absent) | @@ -44,9 +44,9 @@ chain succeeds. ## Right now (frontier) - The stock guest driver initializes fully; the CUDA client reaches - `cuCtxCreate` within seconds and now fails with a forced `rc=999` a few - seconds after the compute-channel phase (a timeout path, not an RM error - record). + `cuCtxCreate` within seconds and - with the latest fix - passes the check + that previously forced a `rc=999` timeout, continuing into UVM for minutes. + The final result is being captured on fresh boots. - The per-channel completion counters in guest memory are enumerated, registered and published; the client's per-channel waits clear, and the per-channel GPFIFO work on copy channels is consumed. @@ -71,14 +71,20 @@ chain succeeds. them through the exact counter slot makes **all 20/20 channel releases land** (verified on live boots). The failure is unchanged by that fix, so the counter path was not the gate. -- **The remaining wall is a silent post-compute-phase rollback**: about a - second after the performance-boost control the guest tears down the 20 - channels and returns the context error - while every resource-manager - control was answered successfully and the guest kernel logs no error. The - profile points at the rollback's RPC frees with the GSP health check - running inside the RPC poll. -- Active work: kernel-return probes on the UVM channel lifecycle plus - failure-instant trace capture, to name the event the rollback waits on. +- **The context-creation error is root-caused and fixed**: the emulated GR + information table left four indices zero (the shader-pipe count and + related clock fields), so the client's clock-table validation rejected the + context. Filling them with the real-device values makes the client sail + past the previously fatal check and **run inside UVM for minutes** - + channels advancing, memsets and releases executing - instead of failing in + seconds. +- **Next wall is the push-data path**: with context creation cleared, the + copy-engine pushes need their operand translations; routing those through + pinned translations (previously a missing-entry failure) now lets the + inline writes execute (`memset=860/1653`, `ringops=1687` live). +- Active work: capture the final context-creation result on a fresh boot, + then move to the allocation/copy roundtrip; runs that end with the + guest-agent unresponsive are the known trace-flood starvation, not a panic. - Guest health note: agent/SSH timeouts during a run are usually guest-agent starvation and recover when the client stops; one hard wedge occurred only when pushed memsets were re-enabled, so bulk pushed operations stay disabled |