Drivers and storage routes
A storage library, a GPU kernel driver and Linux peer-DMA support are different components. This page names each dependency and distinguishes open source from mainline support.
The storage routes side by side
| Route | GPU kernel support | Storage integration |
|---|---|---|
| NVIDIA: cuFile + nvidia-fs | Compatible NVIDIA GPU modules. Current nvidia-fs requires the open modules; older releases also supported the proprietary modules. | nvidia-fs shadow pages and NVFS callbacks in a compatible patched NVMe driver. Shadow pages represent the request; they do not imply a host payload copy. |
| NVIDIA: cuFile + PCI P2PDMA | NVIDIA open GPU kernel modules (OpenRM/UVM), with supported GPU/BAR configuration. | GPU BAR memory is represented by Linux P2PDMA device pages. Supported direct I/O and block/NVMe paths consume them without nvidia-fs or its custom NVMe hooks. |
| AMD: hipFile + AIS | AMD amdgpu/KFD with the AIS additions. AMD documents installation through amdgpu-dkms. | The inspected AIS implementation builds P2PDMA-backed vectors for VRAM and submits VFS direct I/O. AIS-specific driver integration is out of tree. |
| Common experimental path: io_uring + DMA-BUF | A GPU exporter whose allocation can be mapped by the NVMe importer; vendor and driver requirements still apply. | LMCache or NIXL submits registered-buffer I/O through the experimental Linux patches. No cuFile, hipFile, nvidia-fs or AIS backend is used. |
NVIDIA documents the NVMe P2PDMA route starting with CUDA 12.8 and OpenRM 570.x, with a supporting kernel and platform configuration. This removes a storage-driver integration dependency; the GPU driver is still required. See the GDS overview and configuration guide.
The traditional nvidia-fs route should not be summarized as “broken on new kernels.” Its NVMe callbacks are absent from stock mainline NVMe; availability depends on the supported driver stack. NVIDIA's nvidia-fs changelog records the move to open-module-only support in 2.17.5. The NVFS source shows the storage callback integration.
AMD Infinity Storage (AIS) is AMD's storage technology and associated driver/runtime support, not a separate upstream Linux subsystem. The inspected KFD AIS source uses P2PDMA. AMD's hipFile setup guide specifies the driver installation, while the compatibility checks test the required driver and runtime entry points.
The base amdgpu/KFD drivers are open-source Linux kernel
drivers with upstream implementations. The out-of-tree dependency here
is the inspected AIS integration. AMD's route does not use an NVIDIA
driver, and out-of-tree AMD code is not thereby proprietary.
OpenRM is a Linux kernel driver
OpenRM refers to NVIDIA's open-source GPU kernel modules and
Resource Manager implementation. Resource Manager (RM) is in
nvidia.ko; the driver stack also includes modules such as
nvidia-uvm and nvidia-drm. These run in the Linux
kernel. CUDA and NVIDIA's Vulkan implementation run in userspace.
The source is dual MIT/GPLv2 licensed. It contains an OS-independent core and Linux interface code. Sharing core code across operating systems does not turn it into a userspace driver. Its matching CUDA/Vulkan userspace components and GPU firmware remain separate, proprietary components. See the open kernel module README.
NVIDIA initially described this code as unsuitable for merging into mainline in its existing form. Its cross-platform internal design and release-coupled interfaces differ from the upstream driver approach. Licensing alone does not resolve that engineering work. The NVIDIA release explanation describes those constraints.
Does CUDA DMA-BUF export require a proprietary kernel module?
The documented CUDA DMA-BUF route requires NVIDIA's open kernel modules. The CUDA userspace driver remains proprietary. Do not confuse the license of that userspace library with the license of the loaded GPU kernel module. NVIDIA's DMA-BUF requirements table specifies the open-module requirement.
On a supported device and allocation, software can query
CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED and export with
cuMemGetHandleForAddressRange using
CU_MEM_RANGE_HANDLE_TYPE_DMA_BUF_FD. These are CUDA APIs,
not cuFile calls. See the CUDA memory API.
OpenRM is necessary for that documented route, but it is not sufficient
for every GPU and allocation. Our records include both a native CUDA
export success and a separate open-module configuration that returned
CUDA_ERROR_NOT_SUPPORTED (801). The latter used the experimental
Vulkan/RM provider instead.
The recorded work does not establish the same storage path under NVIDIA's
closed kernel module.
Where do Nouveau, NVK and Nova fit?
| Component | Role | Status in this evaluation |
|---|---|---|
| Nouveau | Upstream Linux kernel DRM driver for NVIDIA GPUs. DRM means Direct Rendering Manager. | A Vulkan allocation exported a 2 MiB DMA-BUF. That export test did not qualify both GPU ↔ NVMe directions. |
| NVK | Mesa userspace Vulkan driver for NVIDIA GPUs, used with an appropriate kernel driver. | The recorded Nouveau/NVK export is distinct from the later NVIDIA OpenRM + Vulkan/RM storage success. |
| Nova | Rust-based upstream NVIDIA driver effort: nova-core for hardware/firmware foundations and nova-drm for DRM integration. | Future storage exporter enablement and testing are required. No io_uring DMA-BUF storage qualification is recorded here. |
Nouveau does support DMA-BUF sharing. The unresolved question here is whether a particular exported allocation stays in VRAM and maps correctly for NVMe, with visibility and integrity in both directions. “Untested end to end” does not mean “DMA-BUF unsupported.”
Nova is the new upstream Rust driver direction for newer NVIDIA GPUs, with firmware and graphics/memory enablement still evolving. CUDA support is an active development topic, not a capability this storage evaluation has established. Consult the kernel Nova documentation, Rust for Linux project description and October 2026 development report. An upstream driver still needs the same exporter/importer and platform qualification as any other implementation.