diff options
Diffstat (limited to 'docs/README.md')
| -rw-r--r-- | docs/README.md | 38 |
1 files changed, 21 insertions, 17 deletions
diff --git a/docs/README.md b/docs/README.md index 5f9a32f..5057c9f 100644 --- a/docs/README.md +++ b/docs/README.md @@ -57,7 +57,7 @@ flowchart TB classDef hw fill:#e2e8f0,stroke:#4a5568 class E,F done class G wip - class H plan + class H wip class I hw ``` @@ -108,7 +108,7 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai- | GSP-RM controls: device/fb/bus tables, CE caps, vaspace, GMMU static info | 🟡 Mostly — the engine inventory now includes the async copy engine and the CE capabilities match the device; reply fidelity for the remaining consumed fields is still being tightened | | Guest `nvidia.ko` probe, `nvidia-smi` | ✅ Working (TU104) | | Guest CUDA driver (`libcuda`) startup | ✅ Driver-API baseline — `cuInit`, device enumeration, `cuCtxCreate`, `cuMemAlloc`, copies, free and destroy complete end to end; the smoke test prints `ALL OK` and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-01 on the current build). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) | -| CUDA kernel execution | 🔴 Not yet — the runtime client initializes and the kernel launch is queued, but execution awaits the backend; the mechanism is chosen (module-owned GPU + real GSP session) with ownership + firmware staging verified and the power-domain lock implemented pending supervised verification ([`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md)); the real GSP boot has not started, and today only decoded memsets/copies/semaphore releases execute, in the host | +| CUDA kernel execution | 🟡 The backend is live: the module owns the physical GPU and its real GSP-RM initialized, serves the full static-config reply and shuts down cleanly; a host resource-manager client now allocates memory/VAS/page-directory/TSG/channel and has executed the first real copy on the physical copy engine (4 KiB, semaphore released, dst==src, 2026-10-01). What remains is wiring that session into the guest-facing path so guest submissions execute there ([`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md)); see also [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md) | | OpenGL / Vulkan | 🔴 Not yet | | Windows guest | 🔴 Not yet | | Multi-tenant isolation (VFs, mdev-per-VM) | 🟡 Designed, partially implemented | @@ -121,13 +121,16 @@ returns and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-01 on the current build). The full mechanism, with offsets and the decompiled call path, is in [`../userspace/cuda/docs/05-570.144-decompilation.md`](../userspace/cuda/docs/05-570.144-decompilation.md). -The remaining frontier is real execution on the physical GPU: the runtime client -initializes and queues a kernel launch, but does not execute it. The chosen -backend — a module-owned GPU running its real GSP firmware as the -resource-manager server — has verified ownership + firmware staging and an -implemented (pending supervised verification) power-domain lock; the real GSP -boot has not started. It is specified in -[`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md). +The remaining frontier is guest-facing execution: the runtime client initializes +and queues a kernel launch, and the physical backend now executes real work (the +first copy-engine transfer completed on hardware — 4 KiB with the semaphore +released and dst==src, 2026-10-01) — but the two planes are not yet wired +together. The backend, a module-owned GPU running its real GSP firmware as the +resource-manager server, is specified in +[`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md); +the bridge from the live session to the guest-facing mdev/VFIO path is specified +in +[`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md). For the visual end-state map and the cross-component call paths, see [`03-architecture/09-full-system-picture.md`](03-architecture/09-full-system-picture.md) @@ -160,14 +163,15 @@ Read in order if you are new. Jump directly if you know what you need. | 11 | [Host module and hybrid model](03-architecture/06-host-module-and-hybrid-model.md) | developers | 25 min | | 12 | [Driver lifecycle field guide](03-architecture/07-driver-lifecycle-field-guide.md) | developers, debuggers | 30 min | | 13 | [Physical GPU integration](03-architecture/08-physical-gpu-integration.md) | developers, architects | 20 min | -| 14 | [Known-knowns and known-unknowns](04-implementation/01-known-knowns-and-unknowns.md) | everyone technical | 25 min | -| 15 | [Practical challenges and adversarial interoperability](04-implementation/02-practical-challenges-and-adversarial-interop.md) | developers, stakeholders | 20 min | -| 16 | [Performance, correctness, security](05-operations/01-performance-correctness-security.md) | developers, auditors | 25 min | -| 17 | [Debugging and maintenance workflows](05-operations/02-debugging-and-maintenance-workflows.md) | developers, maintainers | 25 min | -| 18 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min | -| 19 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min | -| 20 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min | -| 21 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference | +| 14 | [Physical backend guest wiring](03-architecture/11-physical-backend-guest-wiring.md) | developers, architects | 25 min | +| 15 | [Known-knowns and known-unknowns](04-implementation/01-known-knowns-and-unknowns.md) | everyone technical | 25 min | +| 16 | [Practical challenges and adversarial interoperability](04-implementation/02-practical-challenges-and-adversarial-interop.md) | developers, stakeholders | 20 min | +| 17 | [Performance, correctness, security](05-operations/01-performance-correctness-security.md) | developers, auditors | 25 min | +| 18 | [Debugging and maintenance workflows](05-operations/02-debugging-and-maintenance-workflows.md) | developers, maintainers | 25 min | +| 19 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min | +| 20 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min | +| 21 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min | +| 22 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference | Deep-dive material lives in [`../wiki/`](../wiki/README.md) (firmware decompilation record, address reference, historical protocol notes). Wiki |