summaryrefslogtreecommitdiffstats
path: root/docs/03-architecture/02-guest-stack-and-cudasw.md
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-09-29 15:29:00 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-09-29 15:29:00 -0400
commit4738b619c45abc4cf98a549c3118839e48bb7244 (patch)
treecb6004f1a6351edbc482031189d359fd2882dab5 /docs/03-architecture/02-guest-stack-and-cudasw.md
parent8d45a99fe54cb2b19b3024fd975ab11574611c3e (diff)
downloadopen-iov-4738b619c45abc4cf98a549c3118839e48bb7244.tar.gz
open-iov-4738b619c45abc4cf98a549c3118839e48bb7244.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.md12
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 —