From 1fdbf4ea8c17dab2b8fca6b5e58c2a6d3bc7596d Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Tue, 29 Sep 2026 15:29:00 -0400 Subject: docs: record physical-GPU integration mechanism and refresh project status - add docs/03-architecture/08-physical-gpu-integration.md: interfaces that exist, mechanism options A-E, chosen path (module-owned GPU driven through its real GSP firmware), sharing policy, decision record - update 06-host-module-and-hybrid-model, 02-practical-challenges, system overview, known-knowns, docs/README reading order and CUDA-side docs to match - correct stale engine-topology/COPY14 blocker claims across the tree - add STATE-CURRENT.md as the dated public status snapshot --- docs/03-architecture/01-system-overview.md | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) (limited to 'docs/03-architecture/01-system-overview.md') diff --git a/docs/03-architecture/01-system-overview.md b/docs/03-architecture/01-system-overview.md index c7a847e..5c2ba6c 100644 --- a/docs/03-architecture/01-system-overview.md +++ b/docs/03-architecture/01-system-overview.md @@ -61,10 +61,12 @@ HOST MODULE open-iov-vfio.ko ├─ emulation core: GSP boot + GSP-RM (RPC msgq, controls, objects, events) ├─ memory model: guest RAM access, VA↔PA maps, VRAM backing └─ work path: channel/push forwarding to the physical GPU [goal; software bridge today] - │ -HOST DRIVER nvidia.ko (unmodified) and/or direct GPU interfaces - │ -PHYSICAL GPU + │ module-owned device + real GSP session +HOST BACKEND the GPU's own hardware + GSP firmware, driven by this module + │ (the distribution nvidia.ko stays unmodified and unbound in + │ this mode; see 08-physical-gpu-integration.md) + v +REAL HARDWARE (engines, memory, interrupts) ``` ## 3. Host module architecture @@ -167,11 +169,12 @@ decompiled and mapped (see `wiki/GSP-570.144W-Firmware-Analysis.md` and `SUCCESS` with zeroed params, and `GSP_RM_ALLOC` echoes the request params without server-side object management. Where the driver consumes a reply value, that value is still being corrected (the reply-fidelity ladder). -5. `nvidia-smi` works; CUDA user-space starts (`cuInit` / `cuDeviceGet` - succeed). Context creation is currently blocked: `cuCtxCreate` returns - `rc=999` (`CUDA_ERROR_UNKNOWN`) because the emulated engine list lacks the - async copy engine (`COPY14`), so UVM's channel-manager and page-tree - initialization is as far as the guest gets. +5. `nvidia-smi -L` enumerates the emulated device and CUDA user-space starts + (`cuInit` / `cuDeviceGetCount` / `cuDeviceGet` succeed). The client reaches + `cuCtxCreate`, which currently ends in a forced `rc=999` on a completion + wait; the copy-engine method streams execute in software as a bridge, and + the execution backend is not built yet (see + [`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)). The CUDA-side contract and the reply-fidelity rules are documented in [`../../userspace/cuda/docs/03-driver-and-gpu-interface.md` §9](../../userspace/cuda/docs/03-driver-and-gpu-interface.md) @@ -192,7 +195,9 @@ That means the host module must: faults and semaphores back. The design for this, including what is known and what remains to be learned, is -in: +in [`../04-implementation/01-known-knowns-and-unknowns.md`](../04-implementation/01-known-knowns-and-unknowns.md) and -[`../04-implementation/02-practical-challenges-and-adversarial-interop.md`](../04-implementation/02-practical-challenges-and-adversarial-interop.md). +[`../04-implementation/02-practical-challenges-and-adversarial-interop.md`](../04-implementation/02-practical-challenges-and-adversarial-interop.md); +the chosen execution backend is specified in +[`08-physical-gpu-integration.md`](08-physical-gpu-integration.md). -- cgit v1.2.3