mirror of
https://github.com/netbirdio/gvisor.git
synced 2026-05-22 17:12:49 -07:00
Update GPU support documentation about graphics and video workload support.
e6e1ecbdcc("Add support for graphics in nvproxy.") and7399a32b4c("Add GPU video codecs support to nvproxy (so that tools like ffmpeg work)") added support for additional driver capabilities. PiperOrigin-RevId: 723655991
This commit is contained in:
Ayush Ranjan
gVisor bot
+32
-13
@@ -2,7 +2,7 @@
|
||||
|
||||
[TOC]
|
||||
|
||||
gVisor adds a layer of security to your AI/ML applications or other CUDA
|
||||
gVisor adds a layer of security to your AI/ML applications or other GPU
|
||||
workloads while adding negligible overhead. By running these applications in a
|
||||
sandboxed environment, you can isolate your host system from potential
|
||||
vulnerabilities in AI code. This is crucial for handling sensitive data or
|
||||
@@ -13,7 +13,7 @@ gVisor supports running most CUDA applications on preselected versions of
|
||||
To achieve this, gVisor implements a proxy driver inside the sandbox, henceforth
|
||||
referred to as `nvproxy`. `nvproxy` proxies the application's interactions with
|
||||
NVIDIA's driver on the host. It provides access to NVIDIA GPU-specific devices
|
||||
to the sandboxed application. The CUDA application can run unmodified inside the
|
||||
to the sandboxed application. The GPU application can run unmodified inside the
|
||||
sandbox and interact transparently with these devices.
|
||||
|
||||
## Environments
|
||||
@@ -31,7 +31,7 @@ This runtime is just a shim and delegates all commands to the configured low
|
||||
level runtime (which defaults to `runc`). To use gVisor, specify `runsc` as the
|
||||
low level runtime in `/etc/nvidia-container-runtime/config.toml`
|
||||
[via the `runtimes` option](https://github.com/NVIDIA/nvidia-container-toolkit/tree/main/cmd/nvidia-container-runtime#low-level-runtime-path)
|
||||
and then run CUDA containers with `nvidia-container-runtime`. The `runtimes`
|
||||
and then run GPU containers with `nvidia-container-runtime`. The `runtimes`
|
||||
option allows to specify an executable path or executable name that is
|
||||
searchable in `$PATH`. To specify `runsc` with specific flags, the following
|
||||
executable can be used:
|
||||
@@ -82,9 +82,10 @@ So k8s environments other than GKE might not be supported.
|
||||
gVisor supports a wide range of CUDA workloads, including PyTorch and various
|
||||
generative models like LLMs. Check out
|
||||
[this blog post about running Stable Diffusion with gVisor](/blog/2023/06/20/gpu-pytorch-stable-diffusion/).
|
||||
gVisor undergoes continuous tests to ensure this functionality remains robust.
|
||||
gVisor also supports Vulkan and NVENC/NVDEC workloads. gVisor undergoes
|
||||
continuous tests to ensure this functionality remains robust.
|
||||
[Real-world usage](https://github.com/google/gvisor/issues?q=is%3Aissue+label%3A%22area%3A+gpu%22+)
|
||||
of gVisor across different CUDA workloads helps discover and address potential
|
||||
of gVisor across different GPU workloads helps discover and address potential
|
||||
compatibility or performance issues in `nvproxy`.
|
||||
|
||||
`nvproxy` is a passthrough driver that forwards `ioctl(2)` calls made to NVIDIA
|
||||
@@ -110,8 +111,9 @@ As a result, `nvproxy` has the following limitations:
|
||||
|
||||
1. Supports selected GPU models.
|
||||
2. Supports selected NVIDIA driver versions.
|
||||
3. Supports selected NVIDIA device files.
|
||||
4. Supports selected `ioctl`s on each device file.
|
||||
3. Supports selected NVIDIA driver capabilities.
|
||||
4. Supports selected NVIDIA device files.
|
||||
5. Supports selected `ioctl`s on each device file.
|
||||
|
||||
### Supported GPUs {#gpu-models}
|
||||
|
||||
@@ -161,6 +163,23 @@ is **not officially supported**, and running old drivers is generally not secure
|
||||
as many driver updates address security bugs. Bug reports with the
|
||||
`--nvproxy-driver-version` flag set will be treated as invalid.
|
||||
|
||||
### Supported Driver Capabilities {#driver-capabilities}
|
||||
|
||||
The `NVIDIA_DRIVER_CAPABILITIES` environment variable defined in the container
|
||||
spec controls which driver libraries/binaries will be mounted inside the
|
||||
container. Different GPU workloads may have varying requirements. For instance,
|
||||
Vulkan requires `graphics` capability, CUDA requires `compute`, while
|
||||
NVENC/NVDEC requires `video`.
|
||||
|
||||
`nvproxy` supports the following driver capabilities: `compute`, `utility`,
|
||||
`graphics` and `video`. By default, `nvproxy` only allows `compute` and
|
||||
`utility`. If additional capabilities are required, then please set runsc flag
|
||||
`--nvproxy-allowed-driver-capabilities` with a comma-separated list of
|
||||
capabilities to allow. Allowing additional capabilities broadens the host driver
|
||||
surface exposed to the sandbox, so provision this flag conservatively. Passing
|
||||
"all" will allow all supported capabilities. If `NVIDIA_DRIVER_CAPABILITIES=all`
|
||||
then all allowed capabilities will be used.
|
||||
|
||||
### Supported Device Files {#device-files}
|
||||
|
||||
gVisor only exposes `/dev/nvidiactl`, `/dev/nvidia-uvm` and `/dev/nvidia#`.
|
||||
@@ -178,13 +197,13 @@ Some unsupported NVIDIA device files are:
|
||||
|
||||
To minimize maintenance overhead across supported driver versions, the set of
|
||||
supported NVIDIA device `ioctl`s is intentionally limited. This set was
|
||||
generated by running a large number of CUDA workloads in gVisor. As `nvproxy` is
|
||||
generated by running a large number of GPU workloads in gVisor. As `nvproxy` is
|
||||
adapted to more use cases, this set will continue to evolve.
|
||||
|
||||
Currently, `nvproxy` focuses on supporting compute workloads (like CUDA).
|
||||
Graphics and video capabilities are not yet supported due to missing `ioctl`s.
|
||||
If your GPU compute workload fails with gVisor, please note that some `ioctl`
|
||||
commands might still be unimplemented. Please
|
||||
Currently, `nvproxy` focuses on supporting compute, graphics and video workloads
|
||||
(like CUDA, Vulkan and NVENC/NVDEC). If your GPU compute workload fails with
|
||||
gVisor, it might be because some `ioctl` commands are still be unimplemented.
|
||||
Please
|
||||
[open a GitHub issue](https://github.com/google/gvisor/issues/new?labels=type%3A+bug,area%3A+gpu&template=bug_report.yml)
|
||||
to describe about your use case. If a missing `ioctl` implementation is the
|
||||
problem, then the [debug logs](/docs/user_guide/debugging/) will contain
|
||||
@@ -249,7 +268,7 @@ Alternatively, you can also just pass the runsc flag `--host-settings=enforce`.
|
||||
|
||||
## Security
|
||||
|
||||
While CUDA support enables important use cases for gVisor, it is important for
|
||||
While GPU support enables important use cases for gVisor, it is important for
|
||||
users to understand the security model around the use of GPUs in sandboxes. In
|
||||
short, while gVisor will protect the host from the sandboxed application,
|
||||
**NVIDIA driver updates must be part of any security plan with or without
|
||||
|
||||
Reference in New Issue
Block a user