1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
# DirectX
> **Scope.** The Windows guest path — Direct3D and the rest of the DirectX
> family — as a **project target**: how the Windows NVIDIA stack relates to
> the interface Open-IOV already emulates for Linux, what a bring-up would
> require, and what has *not* happened yet (no Windows guest has been booted
> on the emulated vGPU). Linux graphics is covered on
> [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and
> [`Graphics-Execution.md`](Graphics-Execution.md). Canonical sources:
> [`../docs/03-architecture/02-guest-stack-and-cudasw.md`](../docs/03-architecture/02-guest-stack-and-cudasw.md)
> (guest stack) and
> [`../docs/06-portability/hardware-software-matrix.md`](../docs/06-portability/hardware-software-matrix.md)
> (support ladder). The docs tree wins on disagreement.
Status: 2026-10-30, tree `master @ b4930168`. Tags: `[target]` designed for,
bring-up not started; `[planned]` roadmap; no Windows-specific code exists in
the project today.
## 1. The Windows graphics stack
```text
Direct3D application (D3D12 / D3D11 / D3D9) or CUDA application
-> DXGI (swap chains, adapters, presentation)
-> user-mode display driver (UMD): nvd3dumx / nvwgf2umx [D3D]
-> kernel-mode driver (KMD): nvlddmkm.sys, under WDDM
-> GPU
Windows kernel graphics subsystem (dxgkrnl)
-> GPU scheduler, video-memory manager (VidMm), residency, TDR
```
Two structural differences from Linux matter for this project:
* **WDDM owns more of the pipeline.** The OS schedules command buffers
submitted by the UMD, manages video-memory residency, and runs the GPU
scheduler in the kernel; the driver's KMD programs hardware contexts and
fences beneath that. (D3D12 exposes queues and fences with an explicit
model that is closer to Vulkan than older APIs were.)
* **The device bring-up is different.** A Windows display adapter starts
through the OS's display/PDO path (adapter enumeration, ROM/VBIOS views,
VIDPN topology, power transitions), not the Linux DRM/modeset path. On
Turing and later, however, the driver still talks to the **same GSP
firmware resource manager** — the interface `vgsp.ko` emulates.
CUDA on Windows rides the same KMD with its own userspace driver, so the
device-facing requirements overlap almost entirely with the Linux CUDA work
already proven ([`Execution-Frontier.md`](Execution-Frontier.md)).
## 2. What this means for Open-IOV
The project's architecture does not change for Windows: **emulate the
firmware interface, pass the work through, patch nobody.** The Windows KMD
would be stock (signed, as shipped); the emulation must satisfy its
device-view and its GSP-RM usage. The measured bring-up items, from
[`../docs/06-portability/hardware-software-matrix.md`](../docs/06-portability/hardware-software-matrix.md):
* WDDM device start on the emulated device (PDO/display path, MSI-X and
interrupt semantics).
* ROM/VBIOS provisioning in the device profile (Windows adapters expect one).
* Power-management transitions (Dx states) and reset behaviour.
* D3D/DXGI device creation, then compute (CUDA on Windows), then rendering
through the same execution lanes as Linux.
## 3. Status
| Item | State |
|---|---|
| Windows guest boots on the emulated vGPU | `[planned]` — not started |
| KMD (`nvlddmkm.sys`) initialises on the emulated device | `[target]` |
| CUDA on Windows (driver-API smoke) | `[target]` |
| Direct3D device creation / rendering | `[target]` |
| Multi-VM Windows guests | `[target]` |
The support matrix lists **Windows x86_64 (WDDM driver, CUDA, 3D)** as
**Target**: the architecture is designed for it; the bring-up is ahead. The
proposed ladder mirrors the Linux milestones: KMD initialises → adapter
enumeration healthy → CUDA-on-Windows driver-API smoke → D3D device creation
→ first compute execution → first rendered pixels → multiple VMs.
## 4. What the project will not do
* No Windows-specific code inside the guest — no patched `nvlddmkm`, no
shims in the guest kernel, no guest agent. Any Windows-only quirk belongs
in the host module's device model.
* No reliance on the vendor vGPU host stack; the same mediator answers both
guest OS families.
* The two-VM GPU demo videos published so far used **Linux** guests (and, for
the `virgl` variant, a labelled non-vGPU path); neither is DirectX.
## 5. Related pages
* [`Graphics-Execution.md`](Graphics-Execution.md) — the execution lanes
Direct3D would use.
* [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) — the Linux API paths,
further along.
* [`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) — the support
ladder, including the Windows target row.
* [`Guest-Stack-and-CUDASW.md`](Guest-Stack-and-CUDASW.md) — §7 covers
the Windows kernel-mode driver and the no-guest-code rule.
* [`../docs/06-portability/hardware-software-matrix.md`](../docs/06-portability/hardware-software-matrix.md) —
the canonical matrix and what each support level means.
|
