diff options
Diffstat (limited to 'docs/03-architecture/06-host-module-and-hybrid-model.md')
| -rw-r--r-- | docs/03-architecture/06-host-module-and-hybrid-model.md | 33 |
1 files changed, 33 insertions, 0 deletions
diff --git a/docs/03-architecture/06-host-module-and-hybrid-model.md b/docs/03-architecture/06-host-module-and-hybrid-model.md index 7f670d7..dbf0c00 100644 --- a/docs/03-architecture/06-host-module-and-hybrid-model.md +++ b/docs/03-architecture/06-host-module-and-hybrid-model.md @@ -224,6 +224,38 @@ and the kernel-side bookkeeping records physical pages without a GPU VA. Until a durable join is implemented, a session can feed verified pairs with the `sema_map_add` debug parameter. +### 4.4 Copy execution rules (correctness invariants) + +Two rules are load-bearing for any client-visible data transfer; both were +established by live differential runs of a device-to-host/host-to-device +pipeline: + +1. **A decoded copy runs at most once per GPFIFO entry.** The service pump + intentionally replays recently consumed ring entries when a new batch of + translations is injected (so releases that previously missed a + translation can land). Release application is forward-progress guarded, + but *copy execution is not idempotent*: a CE copy may read a client + staging buffer that the client has since refilled for the next chunk, so + re-running a consumed copy overwrites finished data with the next chunk's + bytes (observed as a deterministic corruption pattern in the transferred + buffer). The pump therefore records the raw GPFIFO entry words + (`e0 | e1 << 32`) per slot and, when a replayed entry matches the recorded + identity, suppresses its operations while still processing releases. A + slot whose entry words change (a recycled slot in a later epoch) executes + normally. +2. **A virtual operand is translated per 4 KB page.** A GPU VA range is a + list of independent page mappings; resolving only the first page and + walking the physical address linearly is correct only while the mapping + is physically contiguous. Client staging buffers are frequently split + (a 1 MB range was observed as 195 contiguous pages plus 61 pages + elsewhere), so a linear walk reads unrelated memory past the split. Every + multi-page copy translates each page through the same trusted resolver + (pins, learned map, published page directories, targeted resolve) before + moving its 256-byte bounce. + +The same page-granular discipline already applies to the host-side bridge +read/write helpers and to semaphore I/O. + ## 5. The forwarding path (design) ``` @@ -332,6 +364,7 @@ in `kernel-open` first). | Message queues + RPC + all init controls observed from stock 570.144 | implemented | | Guest sysmem access + VA↔PA discovery | implemented (debug-grade, to be productized) | | Push decoding + semaphore completion | demonstrated live; being productized | +| Emulation-mode CUDA end-to-end (host bridge executes client kernels on the physical GPU) | verified live and repeatable: mail kernel bytes authored by GPU execution and read back, `vectorAdd` over 1 M elements returning `bad=0` and the reference checksum, deterministic across consecutive supervised cycles (see `docs/04-implementation/01-known-knowns-and-unknowns.md`) | | Guest-RAM physical path | implemented default-off: guest RAM is file-backed shared memory and GPA→HPA goes through its page cache, verified live on the CE | | Page-table population for server-owned ranges | implemented default-off: forwarded CE copies map resolved host pages through module-built GMMU scratch page tables; real guest page tables remain | | GPU work forwarding (GR/CE execution) | CE forwarding, engine-authored release relay and fault relay implemented default-off and verified live; GR execution open | |