What Is the /dev/dxg Linux Driver Architecture?

The /dev/dxg driver architecture is a GPU paravirtualization framework developed by Microsoft that enables Linux virtual machines, most notably the Windows Subsystem for Linux (WSL2), to access the host system's GPU hardware. By exposing a virtual device node named /dev/dxg inside the Linux guest, the architecture mirrors the Windows DirectX Graphics Kernel (dxgkrnl) interface, allowing Linux applications to offload graphics, machine learning, and compute tasks directly to the physical GPU managed by Windows.

The Problem Solved by Paravirtualization

Traditionally, giving a virtual machine direct access to a GPU required Discrete Device Assignment (DDA), also known as GPU passthrough. While DDA offers near-native performance, it completely disconnects the GPU from the host operating system, dedicating the hardware exclusively to the guest.

The /dev/dxg architecture replaces full passthrough with GPU paravirtualization (GPU-PV). It allows the host and guest systems to concurrently share the same physical graphics hardware. Windows retains full ownership and scheduling authority over the GPU, while Linux processes receive hardware acceleration for APIs such as Direct3D 12, OpenCL, Vulkan (via Dozen/Mesa), and CUDA.

Architectural Layers

The architecture connects user-space Linux applications to the underlying graphics card through several distinct components across the guest and host boundary:

  1. Linux User-Space Libraries: Linux applications do not communicate with the driver directly through standard graphical APIs. Instead, specialized user-space libraries—such as a custom Mesa Direct3D 12 Gallium driver, the NVIDIA CUDA driver, or Microsoft's DirectML engine—translate API instructions into Direct3D Kernel-Mode Thunk (D3DKMT) calls.
  2. The /dev/dxg Device Node: The user-mode drivers issue standard Linux ioctl commands to the /dev/dxg character device node located in the guest's /dev filesystem.
  3. The Guest dxgkrnl Linux Driver: A companion kernel module within the guest operating system handles these ioctl calls. It serializes and packages the graphics commands, memory allocation requests, and synchronization primitives.
  4. VMBus Channel: The guest driver transmits the serialized requests across the Hyper-V virtual machine bus (VMBus), a high-speed inter-partition communication channel that connects the virtual machine directly to the parent partition (the Windows host).
  5. Host Windows Graphics Subsystem (dxgkrnl.sys): On the host side, the Windows DirectX Graphics Kernel driver receives incoming VMBus packets. It unpacks the requests and forwards them to the standard Windows Display Driver Model (WDDM) stack.
  6. Physical GPU Hardware: The native Windows GPU driver schedules and executes the workloads alongside native Windows applications.

Synchronization and Memory Management

A critical aspect of the /dev/dxg design is unified memory handling. Graphics workloads often involve high-bandwidth data transfers that cannot endure the overhead of continuous memory copies between host and guest.

To maximize throughput, the architecture uses shared memory techniques mapped via the hypervisor. When a Linux process allocates video memory, /dev/dxg communicates with the host to pin and map guest physical address pages directly into the GPU's memory address space. GPU synchronization mechanisms, such as monitored fences, are similarly translated between the Linux driver and the host kernel. This allows native hardware-level scheduling where the GPU signals completion directly to guest threads without requiring host CPU intervention for every frame or compute batch.