diff options
Diffstat (limited to 'docs/04-implementation')
| -rw-r--r-- | docs/04-implementation/01-known-knowns-and-unknowns.md | 29 | ||||
| -rw-r--r-- | docs/04-implementation/02-practical-challenges-and-adversarial-interop.md | 32 |
2 files changed, 49 insertions, 12 deletions
diff --git a/docs/04-implementation/01-known-knowns-and-unknowns.md b/docs/04-implementation/01-known-knowns-and-unknowns.md index 0564ffc..a085211 100644 --- a/docs/04-implementation/01-known-knowns-and-unknowns.md +++ b/docs/04-implementation/01-known-knowns-and-unknowns.md @@ -22,7 +22,10 @@ listed as an unknown-unknown has a *method* by which we will discover it. ### 1.1 Device and platform * A stock 570.144 Linux guest driver probes and initializes against our - emulated TU104 device; `nvidia-smi` works. + emulated TU104 device; `nvidia-smi` works and CUDA user-space starts + (`cuInit`, `cuDeviceGetCount`, `cuDeviceGet`). Context creation does not yet + complete: `cuCtxCreate` returns `rc=999` (`CUDA_ERROR_UNKNOWN`) because the + emulated engine list lacks the async copy engine (`COPY14`). * The same guest **boots unmodified**: no guest code, no guest module parameters are required for the initialization path. * The host is unmodified in the standalone configuration (distribution NVIDIA @@ -77,6 +80,15 @@ it**, **rough cost**. ### 2.1 Execution forwarding +**Immediate blocker (2026-09-23):** the engine topology is not yet right. +`GPU_GET_ENGINES_V2` returns 6 engines (GR + CE0..4) where a bare-metal oracle +returns 7: the async copy engine (`COPY14`; engine descriptor `0x793ceb0e`, +instance 14, client type `0x38`, class pair `0xc9b5`) is missing, so +`cuCtxCreate` returns `rc=999` (`CUDA_ERROR_UNKNOWN`). The zeroed secondary +engine record makes `libcuda` rewrite the channel alloc class to `0x41` +(`NV01_ROOT_CLIENT`) with status `0x19` and roll back. Teardown of the failed +context still oopses in the guest kernel in `uvm_pmm_devmem_page_to_va_space`. + **Unknown:** the correct, isolated way to run a guest's engine work on the physical GPU: which real scheduling primitive to use per engine, how to translate guest pushes to real submissions, and how to relay completion and @@ -129,7 +141,8 @@ forwarded kernel), capture both sides, implement replay; validate with ### 2.4 Version matrix beyond 570.144 **Unknown:** which parts of the observed protocol drift between driver -families (550/560/580/610+), how much is negotiated, and how much must be +families (550/560/570/580 — the families with entries under +`config/versions/`), how much is negotiated, and how much must be configuration. **Why:** durability is a core promise; users will run other versions @@ -269,7 +282,11 @@ tree is the artifact that survives personnel changes. To make a defensible statement, we need all of: 1. **Interfaces:** every guest→device message for the CUDA path is either - answered or forwarded, for the supported driver family. + answered or forwarded, for the supported driver family — and every reply + whose fields the driver consumes is coherent, not just `SUCCESS`-shaped + (the reply-fidelity ladder: status-only → coherent zeroed params → coherent + values for consumed fields → exact values; see + [`../../userspace/cuda/docs/04-virtualization-and-emulation.md` §6](../../userspace/cuda/docs/04-virtualization-and-emulation.md)). 2. **Memory:** every GPU VA used by work is translatable, and every server-owned page-table range is populated correctly. 3. **Execution:** grid launches and copies run on real hardware with correct @@ -283,7 +300,11 @@ To make a defensible statement, we need all of: measured with a published methodology. Until all seven hold, we say "initialization works; execution is in progress", -and we link here. +and we link here. The CUDA-side checklist behind these gates and the current +blocker are in +[`../../userspace/cuda/docs/03-driver-and-gpu-interface.md` §9](../../userspace/cuda/docs/03-driver-and-gpu-interface.md); +start at +[`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md). --- diff --git a/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md b/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md index 1deff02..e2769f8 100644 --- a/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md +++ b/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md @@ -18,7 +18,11 @@ the project portable, maintainable and legally clean. Correctness is not "no crash". It is: * the guest observes the same **values** (capabilities, handles, table - contents) it would on real hardware, + contents) it would on real hardware — a control whose reply fields the + driver consumes is only "implemented" once its reply is coherent, not just + `SUCCESS`-shaped (the reply-fidelity ladder: status-only → coherent zeroed + params → coherent values for consumed fields → exact values; see + [`../../userspace/cuda/docs/04-virtualization-and-emulation.md` §6](../../userspace/cuda/docs/04-virtualization-and-emulation.md)), * the guest observes the same **ordering** (completions happen after the work they signal; faults arrive before replays), * the guest observes the same **failure semantics** (errors are surfaced, not @@ -48,8 +52,10 @@ without a methodology is not accepted in this project. * **Management operations** (object creation, capability queries, mappings) are answered from cached/derived state where the hardware has no side effects the guest can observe. -* **Real work** (grid launches, copies) is forwarded. Nothing else is allowed - on the hot path. +* **Real work** (grid launches, copies) is meant to be forwarded to the + physical GPU (see §3). Today only the work the host decoder understands — + memsets, copies and semaphore releases — is executed in software as a + correctness bridge; no CUDA kernel is forwarded yet. ## 3. Forwarding: the three options and how we choose @@ -99,15 +105,25 @@ means maintaining forks for every guest OS and driver version. A patch to the hypervisor means every hypervisor project must carry it. A firmware change is impossible in practice. +In this repository, patch files exist only as build glue for the *optional* +OpenRM submodule build (`legacy-patches/nvidia/`, applied by `install.sh`). +The runtime and the guest stack are never patched, and the deployment path uses +the distribution driver — so nothing patched is required to run the stack. + ### 5.2 How compliance is verified -* **Contract tests**: CI builds run against *stock* drivers obtained from - distribution repositories (or vendor runfiles), and against *unmodified* - hypervisor packages. +* **Contract tests** (goal): CI builds run against *stock* drivers obtained + from distribution repositories (or vendor runfiles), and against + *unmodified* hypervisor packages. Today CI is push/PR-triggered only — builds, + kernel/unit/KUnit/mock tests, static analysis and docs checks; there is no + scheduled guest suite or stock-driver contract test yet, so the guest ladder + is still run by hand (see the operations docs). * **No-patch checks**: our build must not depend on any patch file for third-party components. Where patches exist in the tree for convenience - (e.g. build glue), the contract tests must pass without them; anything that - fails this is a bug. + (e.g. build glue for the optional OpenRM submodule), they are development + scaffolding only: the contract tests must pass without them, and the + deployment path uses the unpatched distribution driver; anything that fails + this is a bug. * **Behavioral equivalence**: where we answer from emulation, we validate the values against traces from real hardware (or from our decompiled study notes) — not against our own previous answers. |