diff options
| -rw-r--r-- | STATE-CURRENT.md | 34 |
1 files changed, 21 insertions, 13 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 71da3bc..17aab60 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,7 +1,7 @@ # Open-IOV Current State > **Snapshot: 2026-10-05 (reorganized; simulator status current 2026-10-04, -> physical/guest campaign data as of 2026-10-05 ~12:10; debugging-options +> physical/guest campaign data as of 2026-10-05 ~12:16; debugging-options > catalogue added 2026-10-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 @@ -37,9 +37,12 @@ isolation, performance, portability). default off), the V5 channel and the client `MAP_MEMORY_DMA` path, the `TURING_COMPUTE_A` compute-object alloc succeeds, the promote/commit passes and the ladder completes stage 3 (`hGr`, clean releases, no server wedge, - no reboot needed) - the first time. The new wall is stage 4: the submitted - GR semaphore push is not consumed by the engine (`GPGet=0`, no release, - `-110`). + no reboot needed) - the first time. **Update 2026-10-05 ~12:16:** the + stage-4 frontier moved - with a client page-table install (`UPDATE_PDE_2`) + plus a cache flush/PT refill, the GR push is now fetched (`GPGet=1`), but + the GR engine faults during context switch + (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), so no release lands (`-110`); 10 + clean cycles, no wedge, no Xid. - **Guest frontier: FIRST GREEN END-TO-END GUEST CUDA, NOW UNDER HARDENING (2026-10-04 ~16:20; hardening 2026-10-05 overnight).** The emulation-only ("no-claim") campaign runs an unmodified guest CUDA program to completion @@ -109,9 +112,12 @@ isolation, performance, portability). also disables split VAS management (`RMSplitVasMgmtServerClientRm=0`) and the client sends `MAP_MEMORY_DMA` for the ladder buffers - on a shared VAS the server owns the lower page tables, so raw client PTEs are not - authoritative. New wall: stage 4's GR push is submitted but not - fetched/executed by the engine (`GPGet=0`, `-110`). Next: root-cause the - stage-4 non-consumption (GPFIFO fetch, server PDB, doorbell). + authoritative. **Update 2026-10-05 ~12:16:** the stage-4 frontier moved - + a client page-table install plus a cache flush/PT refill makes the GR + PBDMA fetch the submitted push (`GPGet=1`), but the GR engine faults during + context switch (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), so no release + lands (`-110`). Next: root-cause the ctxsw fault (engine-context buffer + init, subcontext header, or a VA+PA promote); 10 clean cycles, no wedge. 2. **Hardening the accepted no-claim path.** The first green guest CUDA acceptance has landed and is holding; the residual classes are (a) corruption via a late first decode behind pump backlog (~3-5% of runs; the experiment @@ -310,7 +316,7 @@ chain succeeds. | ID | Milestone | When | State | |---|---|---|---| -| MS-20261005-02 | GR promote wall crossed on the shared-VAS+srvctx path; new wall = stage-4 push not consumed | 2026-10-05 ~12:00 | srvctx registry (`RMSetClientRMAllocatedCtxBuffer=0`, `RMSplitVasMgmtServerClientRm=0`) + V5 + mode 17 + client `MAP_MEMORY_DMA`; stage 3 completes (`hGr`, clean release, no wedge); stage 4 `GPGet=0`/`-110` | +| MS-20261005-02 | GR promote wall crossed on the shared-VAS+srvctx path; new wall = GR ctxsw fault after push fetch | 2026-10-05 ~12:16 | srvctx registry (`RMSetClientRMAllocatedCtxBuffer=0`, `RMSplitVasMgmtServerClientRm=0`) + V5 + mode 17 + client page-table install/cache flush; stage 3 completes (`hGr`, clean release, no wedge); stage 4 fetches (`GPGet=1`) but GR faults during ctxsw (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), no release, `-110`; 10 clean cycles | | MS-20261005-01 | Hardening the accepted no-claim path (hazard classes closed; rates up) | 2026-10-05 overnight | per-op once bitmap + epoch/content-hash gate + grace 15 s (`b645cf6b`, `3b094c2d`, `c3cd4631`); first-attempt 86% -> ~94-95%; fakes/run 3.39 -> 0.61; hold-all-unreadable/25 s experiment committed (`4115f1dd`, module `e7ff3bf7`), campaign `239..262` validating (`239-242` green; `241a`/`243a` infra retries; `243b` live) | | MS-20261004-04 | **First green end-to-end guest CUDA acceptance** | 2026-10-04 ~16:20 | `noclaim38/39/40` `MAIL` + `VADD n=1048576 bad=0 checksum=392344090.500000` + `STATUS OK`, deterministic, committed `cf6ff542`; 14/15 green in the repeat campaign | | MS-20261004-01 | No-claim bridge reaches the guest `vectorAdd` launch | 2026-10-04 ~14:45 | guest-truth pins + DtoH mail read-back fix + FB 512 MiB; `cudaMalloc` unblocked; no `STATUS OK` yet | @@ -354,11 +360,13 @@ chain succeeds. requirements were source-confirmed and implemented: on a shared VAS the server owns the lower page tables, so the client must send `MAP_MEMORY_DMA` for the ladder buffers, and GSP-RM only serves that RPC - when the srvctx registry also sets `RMSplitVasMgmtServerClientRm=0`. New - wall: stage 4's GR semaphore push is submitted but not fetched/executed by - the engine (`GPGet=0`, no release, `-110`). All ladder cycles released the - device cleanly (no reboot, no Xid, pstore empty); the fixes are uncommitted - in the working tree. + when the srvctx registry also sets `RMSplitVasMgmtServerClientRm=0`. **Update + ~12:16:** the stage-4 frontier moved - with a client page-table install + (`UPDATE_PDE_2`) plus a cache flush/PT refill, the GR PBDMA now fetches the + submitted push (`GPGet=1`), but the GR engine faults during context switch + (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), so no release lands (`-110`). All + ladder cycles released the device cleanly (no reboot, no Xid, pstore empty); + the fixes are now committed (`79d5b65e`). - `MS-20261005-01` **Hardening the accepted no-claim path (2026-10-05 overnight).** Three kernel-side fixes closed the replay/fake hazard classes after the first acceptance: (1) a held-entry retry must not re-run completed |