diff options
Diffstat (limited to 'docs/04-implementation/01-known-knowns-and-unknowns.md')
| -rw-r--r-- | docs/04-implementation/01-known-knowns-and-unknowns.md | 29 |
1 files changed, 25 insertions, 4 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). --- |