STATE-CURRENT + docs: record the freeze fix and the P2/P3 guest-wiring landings

- STATE-CURRENT snapshot moves to the P3 frontier: the host-freeze latch
  and readiness gates are validated, the static identity overlay and the
  read-only control forwarding are landed and live-verified
- the physical-backend guest-wiring design is now marked P0-P3 implemented
  with the P2/P3 acceptance results

1 files changed, 43 insertions, 17 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index fcd9957..f02c742 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-02 01:25.** This is a dated public status page, not live
+> **Snapshot: 2026-10-02 01:55.** 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. |
+   ([`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. |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
@@ -81,21 +81,47 @@ chain succeeds.
 
 ## Right now (frontier)
 
-- **Guest-facing identity wiring (P2) validated live (2026-10-02
-  01:11-01:15).** On a module-owned live GSP-RM session the emulation now
-  overlays the server's real static configuration into the guest-facing
-  identity path: the guest's `nvidia-smi -L` reports `NVIDIA GeForce RTX 2080
-  Super with Max-Q Design` (with a synthetic UUID) instead of the generic
-  emulated identity, while the full driver-API smoke test still passes `ALL
-  OK`. The cycle ran under the supervised harness and released with the
-  latched locks (protected region down, distribution driver rebound, 5 power
-  locks intentionally left held, 0 in-window rail cycles, host stable, no
-  freeze, pstore empty). This is the first live data path of the guest-wiring
-  rung; a control run with the live overlay disabled is in progress (outcome
-  pending). Guest work is still **not** forwarded to the physical engine -
-  the submission/relay wiring is the next rung. The bundle (the default-latched
-  D0/D3cold freeze fix plus the identity overlay) is implemented, built and
-  exercised live, but not yet committed.
+- **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`,
+  `FB_GET_INFO_V2`, `INTERNAL_GMMU_GET_STATIC_INFO`) from the live GSP-RM
+  under the new `gsp_phys_ctrl_forward` parameter (bool, default off). The
+  guest's emulated internal handles are translated to the snapshot's adopted
+  server handles before the forward, and the server's echoed params become the
+  guest reply; everything else falls back to the existing emulated handler
+  (fail-open), counted as forwarded/fallback/timeout. A/B on the full guest
+  smoke: forwarding ON stayed GREEN `ALL OK` 64/64 with counters ok=22
+  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
+  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.
+- **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
+  guest-facing `GET_GSP_STATIC_INFO` reply under the new
+  `gsp_phys_static_live` parameter (bool, default off): a bounded 2 s wait on
+  the READY-time snapshot, fail-open; the snapshot cache is generation-keyed
+  and invalidated on session changes. A/B on the full guest smoke: with the
+  overlay ON the guest's `nvidia-smi -q` Product Name is `NVIDIA GeForce RTX
+  2080 Super with Max-Q Design` (live; overlay applied 4x) and with it OFF it
+  is `NVIDIA GeForce RTX 2080 SUPER` (overlay applied 0); the driver-API
+  smoke stays GREEN `ALL OK` 64/64. FB geometry, masks, engine caps, PDE
+  bases and handles remain emulated in P2. One overlay-OFF full run hit a
+  pre-existing emulated-path flake (the guest wedged in `cuInit` with
+  `rmapiControlCacheSet ... NV_ERR_INVALID_PARAMETER`; no host abort); a
+  subsequent OFF quick run was green, so it is not a P2 regression and is
+  being watched. Release ran latched as designed: WPR2 down, distribution
+  driver rebound, exactly 5 power locks intentionally left held, 0 in-window
+  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.
 - **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