NVIDIA Exploring Ways To Better Support An Upstream Kernel Driver
([Nouveau] 4 Hours Ago
NVIDIA Open Kernel Driver Upstream)
- Reference: 0001470600
- News link: https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD
- Source link:
Here's how an exciting message from a NVIDIA engineer that just hit the mailing list begins: " NVIDIA has been exploring ways to better support the effort for an upstream kernel mode driver for GPUs that are capable of running GSP-RM firmware, since the introduction to Nova. "
As covered back in April first on Phoronix, Nouveau's former lead DRM kernel driver maintainer [1]Ben Skeggs joined NVIDIA and has continued working on the open-source Linux driver support. It turns out as well since word of Red Hat's [2]Rust-written Nova kernel driver in development that is focused on making use of the NVIDIA GSP (GPU System Processor) firmware for engaging the RTX 20 "Turing" GPUs and newer, NVIDIA has been eyeing ways to potentially leverage an upstream open-source kernel driver.
As well versed Phoronix readers are aware, for two years now [3]NVIDIA has been maintaining an open-source kernel driver and that component now used by default on the newer driver releases. But that open-source kernel driver remains out-of-tree and in current form isn't suitable for upstreaming.
But now with the new Nova kernel driver in development, NVIDIA is looking at ways to partially leverage that driver for enhancing their upstream support. In turn this could benefit NVIDIA customer use-cases around virtualization, better security with using an upstream kernel driver, etc.
Ben Skeggs of NVIDIA wrote the following message on [4]dri-devel a few minutes ago to outline their current thinking around having a GPU kernel driver with separate "core" and "DRM" modules:
"NVIDIA has been exploring ways to better support the effort for an upstream kernel mode driver for GPUs that are capable of running GSP-RM firmware, since the introduction to Nova.
Use cases have been identified for which separating the core GPU programming out of the full DRM driver stack is a strong requirement from our key customers.
An upstreamed NVIDIA GPU driver should be able to support current and emerging customer use cases for vGPU hosts. NVIDIA's vGPU deployments to date do not support compute or graphics functionality within the hypervisor host, and have no dependency on the Linux graphics subsystem, instead implementing the minimal functionality required to run vGPU guest VMs.
For security-sensitive environments such as cloud infrastructure, it's important to continue support for running a minimal footprint vGPU host driver in a stripped-down / barebones kernel environment.
This can be achieved by supporting both VFIO and DRM drivers as clients of a core driver, without requiring a full-fledged DRM driver (or the DRM subsystem itself) to be built into the host kernel.
A core driver would be responsible for booting and communicating with GSP-RM, enumeration of HW configuration, shared/partitioned resource management, exception handling, and event dispatch.
The DRM driver would do all the standard things a DRM driver does, and implement GPU memory management (TTM/HMM), KMS, command submission etc, as well as providing UAPI for userspace clients. These features would be implemented using HW resources allocated from a core driver, rather than the DRM driver being directly responsible for HW programming.
As Nouveau's KMD is already split (in the logical sense) along similar lines, we're using it here for the purposes of this RFC to demonstrate the feasibility of such an architecture, and open it up for discussion."
Things continue to heat up for NVIDIA on the open-source Linux graphics driver stack at least as far as their kernel mode driver portion is concerned with no indications of NVIDIA planning to open up any of their user-space driver components around OpenGL, OpenCL, Vulkan, or CUDA.
[1] https://www.phoronix.com/news/Ben-Skeggs-Joins-NVIDIA
[2] https://www.phoronix.com/news/RFC-Rust-Nova-NVIDIA-Driver
[3] https://www.phoronix.com/review/nvidia-open-kernel
[4] https://lore.kernel.org/dri-devel/20240613170211.88779-1-bskeggs@nvidia.com/T/#m17464be2ff30be41d75b214a10102ad60b708812
As covered back in April first on Phoronix, Nouveau's former lead DRM kernel driver maintainer [1]Ben Skeggs joined NVIDIA and has continued working on the open-source Linux driver support. It turns out as well since word of Red Hat's [2]Rust-written Nova kernel driver in development that is focused on making use of the NVIDIA GSP (GPU System Processor) firmware for engaging the RTX 20 "Turing" GPUs and newer, NVIDIA has been eyeing ways to potentially leverage an upstream open-source kernel driver.
As well versed Phoronix readers are aware, for two years now [3]NVIDIA has been maintaining an open-source kernel driver and that component now used by default on the newer driver releases. But that open-source kernel driver remains out-of-tree and in current form isn't suitable for upstreaming.
But now with the new Nova kernel driver in development, NVIDIA is looking at ways to partially leverage that driver for enhancing their upstream support. In turn this could benefit NVIDIA customer use-cases around virtualization, better security with using an upstream kernel driver, etc.
Ben Skeggs of NVIDIA wrote the following message on [4]dri-devel a few minutes ago to outline their current thinking around having a GPU kernel driver with separate "core" and "DRM" modules:
"NVIDIA has been exploring ways to better support the effort for an upstream kernel mode driver for GPUs that are capable of running GSP-RM firmware, since the introduction to Nova.
Use cases have been identified for which separating the core GPU programming out of the full DRM driver stack is a strong requirement from our key customers.
An upstreamed NVIDIA GPU driver should be able to support current and emerging customer use cases for vGPU hosts. NVIDIA's vGPU deployments to date do not support compute or graphics functionality within the hypervisor host, and have no dependency on the Linux graphics subsystem, instead implementing the minimal functionality required to run vGPU guest VMs.
For security-sensitive environments such as cloud infrastructure, it's important to continue support for running a minimal footprint vGPU host driver in a stripped-down / barebones kernel environment.
This can be achieved by supporting both VFIO and DRM drivers as clients of a core driver, without requiring a full-fledged DRM driver (or the DRM subsystem itself) to be built into the host kernel.
A core driver would be responsible for booting and communicating with GSP-RM, enumeration of HW configuration, shared/partitioned resource management, exception handling, and event dispatch.
The DRM driver would do all the standard things a DRM driver does, and implement GPU memory management (TTM/HMM), KMS, command submission etc, as well as providing UAPI for userspace clients. These features would be implemented using HW resources allocated from a core driver, rather than the DRM driver being directly responsible for HW programming.
As Nouveau's KMD is already split (in the logical sense) along similar lines, we're using it here for the purposes of this RFC to demonstrate the feasibility of such an architecture, and open it up for discussion."
Things continue to heat up for NVIDIA on the open-source Linux graphics driver stack at least as far as their kernel mode driver portion is concerned with no indications of NVIDIA planning to open up any of their user-space driver components around OpenGL, OpenCL, Vulkan, or CUDA.
[1] https://www.phoronix.com/news/Ben-Skeggs-Joins-NVIDIA
[2] https://www.phoronix.com/news/RFC-Rust-Nova-NVIDIA-Driver
[3] https://www.phoronix.com/review/nvidia-open-kernel
[4] https://lore.kernel.org/dri-devel/20240613170211.88779-1-bskeggs@nvidia.com/T/#m17464be2ff30be41d75b214a10102ad60b708812
spicfoo