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 --- .../cuda/docs/08-virtualization-approaches.md | 41 ++++++++++++++-------- 1 file changed, 27 insertions(+), 14 deletions(-) (limited to 'userspace/cuda/docs/08-virtualization-approaches.md') diff --git a/userspace/cuda/docs/08-virtualization-approaches.md b/userspace/cuda/docs/08-virtualization-approaches.md index 00ca13f..e67f648 100644 --- a/userspace/cuda/docs/08-virtualization-approaches.md +++ b/userspace/cuda/docs/08-virtualization-approaches.md @@ -20,6 +20,13 @@ principles) and to the project implementation docs (`docs/03-architecture/06-hos fences, some memops) should be satisfied directly in the emulation regardless of A/B/C — they are microseconds in hardware and would lose by round-tripping. +**Availability with an unmodified distribution host driver:** approach A has no +callable entry point from kernel context (see +[`../../../docs/03-architecture/08-physical-gpu-integration.md`](../../../docs/03-architecture/08-physical-gpu-integration.md)); +approach B requires owning scheduling; the project's chosen mechanism is a +module-owned device that keeps the GPU's real GSP firmware as the scheduling +server. Approach E remains deployment-gated. + ## 2. Design implications * Where the boundary sits decides what we must own: A keeps ownership in the @@ -40,25 +47,31 @@ of A/B/C — they are microseconds in hardware and would lose by round-tripping. patch anyone* — a mediated-passthrough vGPU where PCI config/BARs, the GSP boot handshake, the GSP-RM protocol and interrupt routing are emulated in `open-iov-vfio.ko`, while real work is meant to execute on the physical GPU. -The project's own decision procedure is explicit: **prototype A first for -correctness, measure, then move the hot path to B if the budgets demand it** -(option C in practice), with the work path abstracted from day one. +The original decision procedure was to prototype A first for correctness; the +interface analysis +([`../../../docs/03-architecture/08-physical-gpu-integration.md`](../../../docs/03-architecture/08-physical-gpu-integration.md)) +showed that proxying through an unmodified distribution host driver has no +callable entry point from kernel context, so the chosen mechanism is a +**module-owned GPU running its real GSP firmware as the resource-manager +server** (the module becomes the host-side RM client). The work path stays +abstracted from day one so the backend can be swapped. -**Current reality (2026-09, honest):** the *control plane* follows the +**Current reality (2026-09-29, honest):** the *control plane* follows the architecture — GSP-RM emulation, RPC handling, BAR/PCI/MSI-X emulation and object/control replies are implemented, and the guest's stock driver + `libcuda` now get through `cuInit`, `cuDeviceGetCount`/`cuDeviceGet` and into `cuCtxCreate`. The old `cuCtxCreate` segfault is solved (the alloc reply must -echo the request's params — `docs/05` §3.5); context creation is blocked one -step later by engine topology: the class-filtered engine list is missing the -async copy engine, so the walker reads a zeroed secondary record and the call -returns `rc=999` (`docs/05` §3.6). The *data plane* is at the bridge stage: the -host module decodes the guest's push buffers as method streams and **executes -the small work it understands itself** (memsets, copies, semaphore releases) -instead of forwarding it to the physical GPU. No CUDA kernel has been -forwarded yet. So: yes, we are pursuing the intended architecture, but we are -in the "emulate + software-execute state/memory ops" phase of it, with the -A→B/C forwarding decision still ahead. +echo the request's params — `docs/05` §3.5), and the engine inventory is now +complete (the async copy engine is included; the copy-engine capabilities +match the device). Context creation currently ends in a forced `rc=999` on a +completion wait while the completion/translation plumbing is being made +reliable. The *data plane* is at the bridge stage: the host module decodes the +guest's push buffers as method streams and executes the small work it +understands itself (memsets, copies, semaphore releases) instead of forwarding +it to the physical GPU. No CUDA kernel has been forwarded yet; the execution +backend is chosen but not started. So: we are still in the +"emulate + software-execute state/memory ops" phase, with the backend decision +now made (option D in the integration document). **Risks to guard now:** (1) software execution silently becoming the data plane instead of a bridge; (2) the work-path interface being skipped because -- cgit v1.2.3