From 4663825271b8b3a5839876976aa1434b9f4bea6c Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Thu, 1 Oct 2026 20:13:14 -0400 Subject: STATE-CURRENT: 20:12 check-back - first real GPFIFO work submitted to the physical engine; channel now allocates; engine did not execute the block --- STATE-CURRENT.md | 61 ++++++++++++++++++++++++++++++-------------------------- 1 file changed, 33 insertions(+), 28 deletions(-) (limited to 'STATE-CURRENT.md') diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 210c31e..f68fcc0 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-10-01 19:12.** This is a dated public status page, not live +> **Snapshot: 2026-10-01 20: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: @@ -57,16 +57,17 @@ meant to execute on the physical GPU. with a zero result and serve the full static-config reply (GPU name, 8 GiB FB, internal handles, BAR PDE bases, engine caps), and graceful shutdown 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 + 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), 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. | + channel-group objects on the booted server, allocates and programs the + page-directory base of a virtual-address-space object, and **allocates a real + channel** on the live server. It has since filed the **first real submission + to the physical engine**: a copy work item was placed in the channel's GPFIFO + and the doorbell was rung, but the copy engine did not execute it within the + timeout, so no completion was observed - getting the physical channel to run + submitted work is the current wall. One unsafe channel variant hung the server + task earlier, so the fail-safe held the device and an approved reboot restored + it; the variant is removed from the tree. | | Graphics (3D), video | ❌ | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | @@ -78,24 +79,26 @@ chain succeeds. ## Right now (frontier) -- **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: ten memory allocations (system-memory - page-table registrations) and a channel-group object are created under the - 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 +- **Submission-rung bring-up (2026-10-01 17:24-20:12): the first real work + submitted to the physical engine.** A host resource-manager client now talks + to the booted server and the channel-allocation wall has fallen: ten + system-memory page-table registrations and a channel-group object are created + under the server's own internal handles, a virtual-address-space object is + allocated under the device handle, its page-directory base is programmed (the + earlier rejection is fixed), and a real copy-engine channel is allocated. In + the latest cycle the client bound the channel, scheduled it, obtained a + work-submit token, placed a 30-word copy work item in the channel's GPFIFO and + **rang the doorbell** - the first real submission to the physical engine. + The copy engine did **not** execute the work within the timeout (no semaphore + release, the channel made no progress), so completion is not yet observed; + making the physical channel run submitted work is the new wall. The + root-client allocation path remains parked after an invalid-client result. 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/`. + restored the distribution driver (~18:37). The unsafe variant has been removed + from the tree, and a decoded resource-manager log dump makes server-side + failures readable. Evidence: `backups/evidence-20261001-cycle19/` through + `...-cycle21/`. - **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: @@ -420,7 +423,9 @@ Work execution (host service vs client synchronization): launch; the queued compute pushes decode but are not executed [partial] GPU VA -> guest PA translation: page-table walk fixed and succeeding; server-owned page-table population still in progress - [not yet] real work forwarded to the physical GPU (host-RM proxy or direct submission) + [partial] real work submitted to the physical GPU: a copy work item was placed + in a real channel's GPFIFO and the doorbell rung; the engine did not + yet execute it (no completion) [not yet] correct results (vectorAdd) ``` -- cgit v1.2.3