diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-23 12:11:10 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-23 12:11:10 -0400 |
| commit | 13f46e60760cc0855484cc69de913ea34f55c24f (patch) | |
| tree | df67eb2dfc5afd2c56845e514624a4842152a1f1 /docs/03-architecture/06-host-module-and-hybrid-model.md | |
| parent | 21b8ebc9db1d0ae649d6406087ea22b54e3b5775 (diff) | |
| download | open-iov-13f46e60760cc0855484cc69de913ea34f55c24f.tar.gz open-iov-13f46e60760cc0855484cc69de913ea34f55c24f.zip | |
docs: refresh status, supersede stale material, link the CUDA analysis
* Status now matches the live state: guest driver probe and nvidia-smi work;
cuInit/device queries work; cuCtxCreate returns 999 because the emulated
engine list is missing the async copy engine (COPY14). The userspace
libcuda segfault is recorded as solved, with its mechanism (an RM
allocation reply must echo request parameters; zeroing them corrupted the
caller's saved frame pointer).
* Correct the emulation claims: only a subset of RM controls are
special-cased; the rest return a success reply with zeroed parameters whose
consumed fields are still being corrected; allocation replies are coherent
but no server-side object model exists.
* Add the eight-point emulation checklist and reply-fidelity ladder as
explicit gates, documented in userspace/cuda and linked from the
architecture, implementation and operations docs.
* Fix operational errors: build/test commands, module load order, mdev type
names, LFS references, debugfs claims, in-repo firmware claims, CI claims,
portability matrix (guest status, config layout, userspace driver facts).
* Mark historical material: one superseded banner per legacy document with a
pointer to its replacement; STATE.md marked as a 2026-09-21 snapshot.
* Wiki: fix the index, add status banners and in-place factual corrections
(msgq transport vs legacy mailbox, BAR definitions, error statuses,
migration, glossary), and note the archived 2023 imports.
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 | 35 |
1 files changed, 31 insertions, 4 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 fc4bb23..4f9efdb 100644 --- a/docs/03-architecture/06-host-module-and-hybrid-model.md +++ b/docs/03-architecture/06-host-module-and-hybrid-model.md @@ -92,14 +92,39 @@ implementation philosophy: expects, or the driver walks off into uninitialized memory. * **Plausible values second.** Values must be self-consistent (e.g. FB size, BAR sizes, engine counts, page sizes) or later code paths compute nonsense. -* **Never echo garbage.** Queries that pass uninitialized input must receive - zeroed/valid output; echoing the request's stack garbage has caused real - failures. +* **Never invent input.** Queries that pass uninitialized *input* must not read + it; but in/out parameter blocks must be echoed back, because the driver + copies the reply's class parameters over its own buffer at the size the + kernel driver declares. Zeroing an in/out block is destructive: the + `GSP_RM_ALLOC` reply once zeroed a caller's saved frame pointer this way and + faulted `libcuda` (fixed by echoing the request parameters). The handlers currently cover: the boot/static-info exchanges, the device/FB/ BUS/INTR control tables, CE capability and PCE-mask queries, GMMU static info, vaspace reserved-PDE contracts, channel/CE object allocation, and the general -"unknown control returns success with zeroed output" fallback. +"unknown control/function returns success with zeroed output" fallback. The +same fallback now matters for engine inventory: `libcuda` filters the engine +list against the class list, so a missing async copy engine (COPY14) leaves a +record zeroed and blocks context creation (`cuCtxCreate` returns `999`); see +[`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md) +and +[`../../userspace/cuda/docs/05-570.144-decompilation.md`](../../userspace/cuda/docs/05-570.144-decompilation.md) +section 3.7. + +**Current work-execution bridge.** The module also decodes push buffers as +method streams and executes the work it understands in software - memsets, +copies and semaphore releases - and completes the corresponding semaphores. +That is a correctness bridge for memory operations, not the data plane: no +CUDA kernel is forwarded to the physical GPU yet, and the forwarding strategy +(host-RM proxy first, direct submission if needed) is in +[`../04-implementation/02-practical-challenges-and-adversarial-interop.md`](../04-implementation/02-practical-challenges-and-adversarial-interop.md) +section 3. + +**Subsystem status note.** Some components are compiled but not currently +wired into the live path: the physical-GSP load/boot path is skipped in favour +of emulation, and the runtime firmware analyzer, version tables, hardware +abstraction tables and dynamic RPC dispatcher are not yet called by the live +flow. Treat their descriptions here as intended design, not active code. ### 3.3 Event channels and interrupts @@ -193,6 +218,8 @@ emulated device inspectable without rebuilding: | `poke_guest=<gpa>,<v>` | write a 32-bit value to guest physical memory | | `poke_fill=<gpa>,<v>,<n>` | fill a range | | `fill_vidmem=<v>` | fill the VRAM shadow | +| `sema_probe=<gpu_va>[,count]` | probe a semaphore VA and nearby state in guest memory | +| `dump_guest=<gpa>,<len>` | dump guest physical memory (length capped) | These are development-grade but production-useful: they are how the memory model was reverse-engineered, and they remain the fastest way to diagnose a |
