diff options
Diffstat (limited to 'STATE-CURRENT.md')
| -rw-r--r-- | STATE-CURRENT.md | 43 |
1 files changed, 34 insertions, 9 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index f02c742..f15a403 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-10-02 01:55.** This is a dated public status page, not live +> **Snapshot: 2026-10-02 02:25.** 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: @@ -69,7 +69,7 @@ meant to execute on the physical GPU. and destination equal to source. Every cycle released the device cleanly with no reboot; the next rung is wiring the live physical session into the guest-facing mdev/vfio path - ([`docs/03-architecture/11-physical-backend-guest-wiring.md`](docs/03-architecture/11-physical-backend-guest-wiring.md)). The guest-wiring rung then advanced: an inert backend-session API was added, and the mediated-device-owned lifecycle (P1, see the frontier section) was implemented and exercised - deferring the physical claim/boot to the first device create, releasing it on the last remove, with fail-open behaviour. The first P1 acceptance cycle exposed two defects - an asynchronous boot marked READY after a failed FWSEC boot, and the P1 release path freezing the host (see the frontier section). The G0 fix bundle (default-latched D0/D3cold locks, post-rebind readiness gate, pre-claim D0 settle, READY gated on a proven boot, pre-kick staging readback) is implemented, built, smoke-tested and now **validated live**: two module-owned supervised cycles (2026-10-02 ~00:57-00:58) were 2/2 green through claim, FWSEC, booter, RISC-V active, init-done (`0x1001`, `rpc_result=0` in ~955 ms) and a latched release with WPR2 down, exactly 5 `power domain left LOCKED` lines, 0 in-window rail cycles, host alive and pstore empty. The retested P1 mdev-owned path - the exact path that hard-froze on 2026-10-01 - now fails open safely (the READY gate releases the claim when no live GSP-RM session exists; no freeze), while the async FWSEC boot defect (`staging not visible before kick` -> `FWSEC/FRTS execution failed: -5`) remains open, quarantined off the critical path; guest wiring proceeds on the module-owned live session. The bundle is still uncommitted. Guest-wiring P2 (static-config identity overlay) has since landed and verified live (2026-10-02 01:20-01:45): with `gsp_phys_static_live=1` the guest's `nvidia-smi -q` Product Name comes from the live session (`NVIDIA GeForce RTX 2080 Super with Max-Q Design`) versus the emulated `NVIDIA GeForce RTX 2080 SUPER` with it off (A/B; overlay applied 4x/0), while the guest smoke stays GREEN `ALL OK` 64/64; one overlay-OFF full run hit a pre-existing emulated-path flake, watched. P3 (read-only control forwarding) has since landed and verified live (2026-10-02 ~01:33-01:45): the `gsp_phys_ctrl_forward` whitelist served 22 controls live with 2 fallbacks and 0 timeouts while the guest smoke stayed GREEN `ALL OK` 64/64; the next rung is P5 work forwarding + completion relay, with P4 (alloc/free handle adoption) deliberately deferred. | + ([`docs/03-architecture/11-physical-backend-guest-wiring.md`](docs/03-architecture/11-physical-backend-guest-wiring.md)). The guest-wiring rung then advanced: an inert backend-session API was added, and the mediated-device-owned lifecycle (P1, see the frontier section) was implemented and exercised - deferring the physical claim/boot to the first device create, releasing it on the last remove, with fail-open behaviour. The first P1 acceptance cycle exposed two defects - an asynchronous boot marked READY after a failed FWSEC boot, and the P1 release path freezing the host (see the frontier section). The G0 fix bundle (default-latched D0/D3cold locks, post-rebind readiness gate, pre-claim D0 settle, READY gated on a proven boot, pre-kick staging readback) is implemented, built, smoke-tested and now **validated live**: two module-owned supervised cycles (2026-10-02 ~00:57-00:58) were 2/2 green through claim, FWSEC, booter, RISC-V active, init-done (`0x1001`, `rpc_result=0` in ~955 ms) and a latched release with WPR2 down, exactly 5 `power domain left LOCKED` lines, 0 in-window rail cycles, host alive and pstore empty. The retested P1 mdev-owned path - the exact path that hard-froze on 2026-10-01 - now fails open safely (the READY gate releases the claim when no live GSP-RM session exists; no freeze), while the async FWSEC boot defect (`staging not visible before kick` -> `FWSEC/FRTS execution failed: -5`) remains open, quarantined off the critical path; guest wiring proceeds on the module-owned live session. The bundle was later committed (`56766b2`). Guest-wiring P2 (static-config identity overlay) has since landed and verified live (2026-10-02 01:20-01:45): with `gsp_phys_static_live=1` the guest's `nvidia-smi -q` Product Name comes from the live session (`NVIDIA GeForce RTX 2080 Super with Max-Q Design`) versus the emulated `NVIDIA GeForce RTX 2080 SUPER` with it off (A/B; overlay applied 4x/0), while the guest smoke stays GREEN `ALL OK` 64/64; one overlay-OFF full run hit a pre-existing emulated-path flake, watched. P3 (read-only control forwarding) has since landed and verified live (2026-10-02 ~01:33-01:45): the `gsp_phys_ctrl_forward` whitelist served 22 controls live with 2 fallbacks and 0 timeouts while the guest smoke stayed GREEN `ALL OK` 64/64; **P5 wave 1 (guest-submission shadow execution) has since landed and verified live** (2026-10-02 ~02:00-02:20): with `gsp_phys_work_forward=1` the sema pump shadow-executes eligible CE pushes on the physical engine through a dedicated ordered workqueue - 514 real 4 KiB copies during a GREEN guest smoke (`ALL OK` 64/64), 194 requests coalesced/dropped while one was in flight, 0 refusals, 0 timeouts - while the software release path stays authoritative and no guest memory or guest VA is touched; P6 (guest page tables/memory into the real MMU, including the IOMMU/DMA reachability known-unknown) is the next end-to-end rung, P5 wave 2 (hardware-primary release relay) is optional, and P4 (alloc/free handle adoption) remains deliberately deferred. | | Graphics (3D), video | ❌ | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | @@ -81,6 +81,31 @@ chain succeeds. ## Right now (frontier) +- **Guest-submission shadow execution (P5 wave 1) landed and verified live + (2026-10-02 ~02:00-02:20).** Under the new `gsp_phys_work_forward` parameter + (bool, default off) the sema pump requests ONE shadow copy for each eligible + CE push through a dedicated ordered workqueue (`gsp-phys-work`), + coalescing/dropping requests while one is in flight; the work item runs the + ladder channel's module-owned 4 KiB copy via the shared refactored + `gsp_phys_backend_ce_copy_submit()` (rm lock only for clear+methods+GPFIFO+ + GP_PUT+doorbell, then a lock-free semaphore poll <=200 ms). The software + release path remains authoritative and unchanged; refusals/timeouts/drops + are counted; no guest memory or guest VA is touched in wave 1. Full guest + smoke stayed GREEN `ALL OK` 64/64 while the shadow ran **514 real CE copies** + on the physical engine (bytes=4096, elapsed 7-9 ms), with **194 requests + dropped while one was in flight, 0 submit refusals, 0 copy timeouts**. + Release ran latched as designed: rebound `nvidia` (rc=1), exactly 5 `power + domain left LOCKED`, WPR2 down, 0 in-window rail cycles, host stable, no + reboot. Module sha256 `83952506...`; code HEAD `82fc7a8` (`56766b2` carries + the G0+P2/P3/P5-wave-1 code, `82fc7a8` the STATE-CURRENT/design-doc update). + Ladder regression order: trigger 5 (adopt handles) -> trigger 3 (VAS/TSG/ + channel, variant V5 engine COPY0) -> trigger 4 (`REAL COPY OK`); trigger 4 + alone on a fresh session fails at stage 1 with `NV01_ROOT 0x23`, which is + pre-existing expected behavior. **Next: P6** (guest page tables/memory into + the real MMU so guest data itself executes on hardware; includes the + IOMMU/DMA reachability known-unknown), with optional **P5 wave 2** + (hardware-primary release relay with a non-applying decode mode); **P4** + remains deferred. - **Read-only control forwarding (P3) landed and verified live (2026-10-02 01:33-01:45).** `GSP_RM_CONTROL` (fn76) forwards a whitelist of side-effect-free queries (`BUS_GET_PCI_BAR_INFO`, `BUS_GET_INFO_V2`, @@ -94,13 +119,13 @@ chain succeeds. fallback=2 timeout=0, zero reply-send failures and `nvidia-smi -q` working; OFF showed zero forward counters and a healthy guest. Release ran latched as designed: WPR2 down, exactly 5 power locks intentionally held, 0 in-window - rail cycles, host stable, no reboot. Module sha256 `30dfd311...`. **Next: - P5** work forwarding + completion relay (guest submissions shadow-executed - on the physical copy engine). **P4 is deliberately deferred**: the P2-P5 + rail cycles, host stable, no reboot. Module sha256 `30dfd311...`. **P5 wave 1 + has since landed** (guest submissions shadow-executed on the physical copy + engine; bullet above). **P4 is deliberately deferred**: the P2-P5 plan itself states P5 wave 1 does not require it, and adopting real handles would change guest-visible handles and risk the currently green guest path. - The P2/P3 bundles and the G0 freeze fix remain uncommitted in the working - tree. + The P2/P3/P5-wave-1 bundles and the G0 freeze fix are now committed + (`56766b2`, `82fc7a8`; HEAD `82fc7a8`). - **Guest-facing identity wiring (P2) landed and verified live (2026-10-02 01:20-01:45).** On a module-owned live GSP-RM session the emulation overlays the server's real static configuration identity into the @@ -121,7 +146,7 @@ chain succeeds. rail cycles, host stable, no reboot. Module sha256 `69eac176...`. P3 read-only control forwarding has since landed and verified live (bullet above). Guest work is still **not** forwarded to the physical engine. The - P2 bundle and the G0 freeze fix remain uncommitted in the working tree. + P2 bundle and the G0 freeze fix have since been committed (`56766b2`). - **G0 fix bundle built after the P1 release-path freeze (2026-10-02 00:55).** The first P1 mdev-owned acceptance cycle ended in the known hard freeze (journal stops, pstore empty): the P1 release path ran outside the supervised @@ -141,7 +166,7 @@ chain succeeds. active, init-done (`0x1001`, `rpc_result=0` in ~955 ms), WPR2 down, `released 0000:01:00.0; rebound to nvidia (rc=1)`, exactly 5 `power domain left LOCKED` lines, 0 in-window rail cycles, host survived, pstore empty; - module sha256 `dde36d92...`. Uncommitted. + module sha256 `dde36d92...`. Committed in `56766b2`. - **Guest-wiring lifecycle (P1) implemented and exercised; retested after G0 (2026-10-02 ~00:58).** A module parameter selects a lifecycle where the physical-GPU claim and boot are deferred to the first mediated device create |