diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-29 15:29:00 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-29 15:29:00 -0400 |
| commit | 1fdbf4ea8c17dab2b8fca6b5e58c2a6d3bc7596d (patch) | |
| tree | cd16ecce1bbbf8e71c17091df843441965f871c1 /docs/03-architecture/02-guest-stack-and-cudasw.md | |
| parent | f4803e303e1e4bfde9f241ec3b6226399d01825d (diff) | |
| download | open-iov-1fdbf4ea8c17dab2b8fca6b5e58c2a6d3bc7596d.tar.gz open-iov-1fdbf4ea8c17dab2b8fca6b5e58c2a6d3bc7596d.zip | |
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
Diffstat (limited to 'docs/03-architecture/02-guest-stack-and-cudasw.md')
| -rw-r--r-- | docs/03-architecture/02-guest-stack-and-cudasw.md | 12 |
1 files changed, 7 insertions, 5 deletions
diff --git a/docs/03-architecture/02-guest-stack-and-cudasw.md b/docs/03-architecture/02-guest-stack-and-cudasw.md index 115f639..e841342 100644 --- a/docs/03-architecture/02-guest-stack-and-cudasw.md +++ b/docs/03-architecture/02-guest-stack-and-cudasw.md @@ -89,11 +89,13 @@ open /dev/nvidia* → cuInit → UVM registration (per process) The initialization path is where compatibility is won or lost; the runtime path is where *execution* is won or lost. Open-IOV's current focus is -pre-forwarding correctness: `cuInit` / `cuDeviceGet` succeed, but context -creation returns `rc=999` (`CUDA_ERROR_UNKNOWN`) because the emulated engine -list lacks the async copy engine (`COPY14`); the forwarding decision -(host-RM proxy vs direct submission) is still ahead (see -[`../../userspace/cuda/docs/08-virtualization-approaches.md`](../../userspace/cuda/docs/08-virtualization-approaches.md)). +pre-forwarding correctness: `cuInit` / `cuDeviceGet` succeed, and the client +reaches context creation, which currently ends in a forced `rc=999` on a +completion wait; the engine inventory is complete and the forwarding decision +is made — a module-owned GPU running its real GSP firmware as the +resource-manager server (see +[`../../userspace/cuda/docs/08-virtualization-approaches.md`](../../userspace/cuda/docs/08-virtualization-approaches.md) +and [`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)). For the CUDA userspace side of this stack — its architecture, how it is built and executes, and the exact kernel/GPU interface contract we must satisfy — |