diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/03-architecture/11-physical-backend-guest-wiring.md | 56 |
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 |