diff options
Diffstat (limited to 'docs/03-architecture/01-system-overview.md')
| -rw-r--r-- | docs/03-architecture/01-system-overview.md | 27 |
1 files changed, 16 insertions, 11 deletions
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). |