STATE-CURRENT: 19:12 check-back - host RM client allocates a VAS on the live GSP-RM; wall moved to the address-space page-directory setup; clean release

1 files changed, 25 insertions, 19 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 733217f..210c31e 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-01 18:47.** This is a dated public status page, not live
+> **Snapshot: 2026-10-01 19:12.** 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:
@@ -59,11 +59,14 @@ meant to execute on the physical GPU.
   works through the unload RPC. Each of cycles 4-13 released the device
   cleanly with no reboot. Since 2026-10-01 17:24 the next rung has both code
   and live results: a host resource-manager client creates memory and
-  channel-group objects on the booted server (nine allocations succeed) and is
-  blocked at channel allocation with an invalid-state result; one unsafe
-  channel variant hung the server task, so the fail-safe held the device and an
-  approved reboot restored it - the variant is removed from the tree. No
-  physical work has been submitted yet. |
+  channel-group objects on the booted server (nine allocations succeed), then
+  allocates a virtual-address-space object under the server's device handle; it
+  is now blocked one step earlier, at programming that address space's
+  page-directory base (the server rejects the page-directory control), so channel
+  allocation is not yet reached. One unsafe channel variant hung the server
+  task, so the fail-safe held the device and an approved reboot restored it -
+  the variant is removed from the tree. No physical work has been submitted
+  yet. |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
@@ -75,21 +78,24 @@ chain succeeds.
 
 ## Right now (frontier)
 
-- **Submission-rung bring-up (2026-10-01 17:24-18:47): the first real
+- **Submission-rung bring-up (2026-10-01 17:24-19:12): the first real
   resource-manager objects on the live GSP-RM.** A host resource-manager
-  client now talks to the booted server: nine memory allocations (system-memory
+  client now talks to the booted server: ten memory allocations (system-memory
   page-table registrations) and a channel-group object are created under the
-  server's own internal handles. The root-client allocation path is parked
-  after the server returned an invalid-client result, and channel allocation
-  is blocked at an invalid-state result; the next experiments are to allocate
-  and pass a virtual-address-space handle, or to vary the memory-descriptor
-  objects. One channel variant hung the server's resource-manager task; the
-  fail-safe held the device instead of handing it back in a wedged state, and
-  an approved reboot restored the distribution driver (~18:37). The unsafe
-  variant has been removed from the tree, and a decoded resource-manager log
-  dump now makes server-side failures readable. No work has been submitted to
-  the physical engine yet. Evidence: `backups/evidence-20261001-cycle14/`
-  through `...-cycle17/`.
+  server's own internal handles, and a virtual-address-space object is now
+  allocated under the device handle too. The root-client allocation path is
+  parked after the server returned an invalid-client result, and the resource
+  manager rejects the control that programs the new address space's
+  page-directory base, so channel allocation is blocked one step earlier than
+  before; the next experiments are to supply the correct page-directory base
+  (or a valid memory descriptor) so a channel can be allocated. One channel
+  variant hung the server's resource-manager task; the fail-safe held the
+  device instead of handing it back in a wedged state, and an approved reboot
+  restored the distribution driver (~18:37). The unsafe variant has been
+  removed from the tree, and a decoded resource-manager log dump now makes
+  server-side failures readable. No work has been submitted to the physical
+  engine yet. Evidence: `backups/evidence-20261001-cycle14/` through
+  `...-cycle18/`.
 - **Physical-backend milestone (2026-10-01 16:45): the host-owned GSP-RM
   completes initialization on the real TU104 and serves the static-config
   RPC.** Three supervised cycles, no reboot, clean release each time: