docs: execution-backend bring-up staged - ownership and firmware staging verified, real boot next

2 files changed, 35 insertions, 6 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 61f10f0..ed92566 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-09-30 22:45.** This is a dated public status page, not live
+> **Snapshot: 2026-09-30 23:45.** 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:
@@ -101,11 +101,17 @@ chain succeeds.
   crashed the guest kernel (a NULL callback in interrupt context) before any
   emulation channel existed - guest-side and untriaged; treat no-watcher runs
   as a known risk. The host stays stable throughout.
-- Execution backend (chosen; bring-up ladder drafted, not started): the
-  module will own the physical GPU and run its real GSP firmware as the
-  resource-manager server, so real work executes with an unmodified host
-  driver and no host daemon; see
+- Execution backend (chosen; bring-up started): the module owns the physical
+  GPU and will run its real GSP firmware as the resource-manager server, so
+  real work executes with an unmodified host driver and no host daemon; see
   [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md).
+  First bring-up steps verified live: a default-off claim path releases the
+  distribution driver from the device, binds the module, maps the BARs and
+  samples the falcon state, then releases and rebinds the distribution driver
+  (host driver still healthy); with the device owned, the matching GSP image is
+  fetched and validated (ELF64 RISC-V, loadable image/version/signature
+  sections identified) and held for the boot stage. The real boot (protected
+  region, secure verification, booter, RISC-V start) is the next stage.
 - Host stability: the host hang class observed on 2026-09-28 (kernel stack
   overflow in a channel snapshot path) is fixed and frame-audited; repeated
   VM load/attach/teardown cycles run without panics or pstore records.
diff --git a/docs/03-architecture/08-physical-gpu-integration.md b/docs/03-architecture/08-physical-gpu-integration.md
index 06df22b..b1ade18 100644
--- a/docs/03-architecture/08-physical-gpu-integration.md
+++ b/docs/03-architecture/08-physical-gpu-integration.md
@@ -88,6 +88,29 @@ WPR2 setup, message queues in host system memory, doorbell, version exchange —
 the same observable stages the guest emulation already models, with the module
 now on the client side.
 
+The bring-up is staged so each step is reversible and independently verified:
+
+1. **Ownership** — the distribution driver is released from the device and the
+   module binds it; BAR0/1/3 are mapped and the falcon state is sampled. On
+   release the module unbinds and the distribution driver is rebound, so the
+   host can always return to its normal driver.
+2. **Firmware staging** — the matching GSP image (the same file the
+   distribution driver would load) is fetched and validated (ELF64 RISC-V;
+   the loadable image section, firmware version and hardware signature blob
+   are identified and held for the boot stage). No device state is touched.
+3. **Boot** — a protected region is laid out in video memory (firmware heap,
+   image, boot binary, reserved areas), the secure-verification stage runs on
+   the security falcon to authorize it, the booter is then run on the
+   security falcon with the address of the boot metadata, and the GSP RISC-V
+   core is started; success is observed as an active RISC-V core plus the
+   firmware's resource manager completing initialization.
+4. **Client** — the module speaks the already-mapped RPC protocol to the real
+   firmware as the client (section 4.3).
+
+Stages 1 and 2 are implemented in the module and verified live (a claim/release
+cycle leaves the host driver working; the staged image parses as expected);
+stage 3 is the current bring-up target.
+
 ### 4.3 Host-side resource-manager client
 
 Using the wire protocol and RPC inventory already mapped for the supported
@@ -139,7 +162,7 @@ per-context scheduling. Tenant policy and fairness are a later layer on top.
 |---|---|
 | Control plane (GSP boot emulation, RPC, BAR/PCI/MSI-X) | done |
 | Software-executed bridge for decoded memory/state operations | in progress (memsets, copies, releases) |
-| Device ownership + real GSP bring-up by the module | not started (the early prototype is to be rebuilt under exclusive ownership) |
+| Device ownership + real GSP bring-up by the module | in progress — reversible claim/release and firmware staging verified; the real boot stage is next |
 | Host-side resource-manager client for real objects/channels | not started |
 | Work translation and real submission | not started |
 | Completion relay through real hardware | not started |