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, 46 insertions, 10 deletions

diff --git a/docs/03-architecture/11-physical-backend-guest-wiring.md b/docs/03-architecture/11-physical-backend-guest-wiring.md
index da440eb..55700b5 100644
--- a/docs/03-architecture/11-physical-backend-guest-wiring.md
+++ b/docs/03-architecture/11-physical-backend-guest-wiring.md
@@ -1,7 +1,12 @@
 # Physical Backend Guest Wiring: Driving the Guest-Facing Emulation from the Live GSP-RM Session
 
-> **Status: design for implementation (2026-10-01). No code from this design is
-> in the tree yet.** The physical backend itself is live: the module-owned
+> **Status: P0-P3 implemented (2026-10-02).** The backend API skeleton (P0),
+> the mdev-owned lifecycle (P1, fail-open; the async FWSEC boot on that path
+> is an open defect off the critical path), the static-config identity
+> overlay (P2, verified live in an A/B run) and the read-only control
+> forwarding whitelist (P3, default off, verified live: ok=22/fallback=2,
+> smoke `ALL OK` 64/64) are in the tree. The physical
+> backend itself is live: the module-owned
 > GSP-RM completes initialization on the real TU104, serves the full
 > static-config reply, and shuts down gracefully. The host resource-manager
 > client ladder has since allocated memory, a virtual-address-space object with
@@ -19,7 +24,8 @@
 > The design was written against the tree at commit `f8e5d3b`; line numbers are
 > advisory and have moved with later commits — anchor by function name when
 > re-grepping. Behaviour claims below are grounded in live evidence from the
-> 2026-10-01 cycles; anything not yet exercised is labelled "not yet run".
+> 2026-10-01 and 2026-10-02 cycles; anything not yet exercised is labelled
+> "not yet run".
 
 ---
 
@@ -93,12 +99,11 @@
 
 ### 0.3 The gap
 
-The two planes never touch. The guest's static answers, controls and objects
-are emulated; the physical session's real handles, real FB geometry, real
-engine caps and real work capability are only visible to debugfs. The bridge
-must be added at exactly three places (see §2): the reply point
-`gsp_rm_send()`, the inbound dispatch point `gsp_rm_handle_element()`, and the
-lifecycle points in `main.c` / `gsp_phys_gpu.c`.
+The two planes now meet only at the lifecycle seam (P0/P1, mdev-owned
+claim/release) and the static-config identity overlay (P2); controls, objects,
+FB geometry, engine caps and work are still emulated. The remaining bridge
+must be added at the reply point `gsp_rm_send()`, the inbound dispatch point
+`gsp_rm_handle_element()`, and the work-plane seams (see §2).
 
 ---
 
@@ -181,7 +186,7 @@ generation counter` so a release cannot deadlock against a forward in flight.
   the existing release still quiesces, runs the FWSEC teardown and refuses to
   rebind with WPR2 up (`gsp_phys_gpu.c:939`). A reboot then needs explicit
   human approval plus a handoff update.
-* **Static-config served before READY:** bounded wait (recommend 2 s) then
+* **Static-config served before READY:** bounded wait (2 s, implemented) then
   pure emulation fallback, with a stat counter; never block the emulation
   thread longer than the guest's own RPC poll can tolerate.
 
@@ -332,6 +337,11 @@ Two grounded warnings:
   Keep emulated caps until the backend can actually service the resulting
   demands (P4+).
 
+**P2 status (2026-10-02):** the name, short-name and VBIOS identity fields are
+now overlaid live behind `gsp_phys_static_live` (A/B verified); the FB
+geometry, masks and engine caps above remain emulated, per these warnings,
+until P4/P6.
+
 ### 4.3 Proposed flow
 
 1. At READY, cache the full fn65 payload (new bytes in the backend session,
@@ -364,6 +374,9 @@ go-ahead, recovery plan, pstore, never unattended
 (`docs/03-architecture/08-physical-gpu-integration.md` §7/§8).
 
 ### P0 - Backend API skeleton (inert)
+* **Status (2026-10-02): implemented.** Session state/refcount plus the locked
+  backend RPC and static-snapshot helpers are in the tree and refuse when the
+  backend is OFF/not-init-done/unloading.
 * **Scope:** new state/refcount/lock in `gsp_phys_gpu.c`; locked
   `backend_rpc()`/`static_snapshot()` in `gsp_phys_booter.c`; no caller
   changes; no behavior change.
@@ -374,6 +387,12 @@ go-ahead, recovery plan, pstore, never unattended
 * **Rollback:** trivial.
 
 ### P1 - Lifecycle wiring (claim on mdev create, release on last remove)
+* **Status (2026-10-02): implemented and exercised live; fail-open.** The
+  first mdev create starts the claim/boot asynchronously and the last remove
+  releases it. The async boot currently fails at FWSEC on this path
+  (`staging not visible before kick`) and the READY gate releases the claim
+  fail-open; the module-owned live session is the proven path (and what P2
+  uses).
 * **Scope:** `main.c` create/remove/init_work/cleanup_work/exit ordering
   (§3 items 3-6); no live answers yet.
 * **Acceptance (supervised, harness `phys_claim_cycle.sh` style):** fresh
@@ -392,6 +411,14 @@ go-ahead, recovery plan, pstore, never unattended
   only; `mdev` emits `-EOPNOTSUPP` from `backend_start()`.
 
 ### P2 - Static-config identity overlay
+* **Status (2026-10-02): implemented and verified live (A/B).** The READY-time
+  snapshot cache and the `gsp_phys_static_live` parameter (bool, default 0)
+  are in the tree. With the overlay on, the guest `nvidia-smi -q` Product
+  Name is the live `NVIDIA GeForce RTX 2080 Super with Max-Q Design`; with it
+  off it is the emulated `NVIDIA GeForce RTX 2080 SUPER`; the driver-API
+  smoke stays green (`ALL OK`, payload 64/64). Only name, short name and
+  VBIOS identity are overlaid; FB geometry, masks, engine caps, PDE bases and
+  handles stay emulated.
 * **Scope:** cache snapshot at READY; overlay allow-list in
   `gsp_rm_build_static_info()`/`gsp_rm_handle_get_static_info()`; module
   parameter; stats. Bounded wait (2 s) then emulation fallback.
@@ -404,6 +431,15 @@ go-ahead, recovery plan, pstore, never unattended
 * **Rollback:** parameter off.
 
 ### P3 - Read-only control forwarding (whitelist)
+* **Status (2026-10-02): implemented and verified live (default off).** With
+  `gsp_phys_ctrl_forward=1` the whitelist (`BUS_GET_PCI_BAR_INFO`,
+  `BUS_GET_INFO_V2`, `FB_GET_INFO_V2`, `INTERNAL_GMMU_GET_STATIC_INFO`) is
+  forwarded over fn76 with the guest's emulated internal handles translated
+  to the snapshot's adopted server handles; the server's echoed params become
+  the guest reply, and everything else falls back to the emulated handler
+  (fail-open; counters forwarded/fallback/timeout). Live acceptance: guest
+  smoke GREEN `ALL OK` 64/64, counters ok=22 fallback=2 timeout=0, guest
+  `nvidia-smi -q` worked.
 * **Scope:** in `gsp_rm_handle_rm_control()` (`:2611`), before the per-cmd
   switch: for an allow-list of side-effect-free queries (FB/BUS/KGR/GMMU/
   CE/display statics), call `backend_rpc()` with the **adopted internal