fix: Provision /dev/nvidia-modeset in both display and graphics

[ehfd]

Reviewers: @elezar @myeolenv

Associated with NVIDIA/nvidia-container-toolkit#1979.

Summary

The modeset device was only mounted into containers that requested the display capability; the graphics capability also requires it. The device mount is now gated on either capability.

Fixes an additional issue regarding /dev/nvidia-modeset discovery in the legacy provisioning interface, within nvc_info.c.

Why This Exists

/dev/nvidia-modeset backs the display-facing paths of the graphics APIs themselves — Vulkan direct-to-display, the EGLDevice/EGLOutput platform, and the presentation machinery used by Wayland compositor stacks — not only the X.Org driver. In options.h, display already implies OPT_GRAPHICS_LIBS, and OPT_DISPLAY gates exactly one thing: this device mount. A container requesting only graphics therefore received the complete graphics library set but not the device node those APIs need.

The NVIDIA Container Toolkit treats graphics and display as a single gate for its graphics injection at the OCI level, and CDI mode injects the device unconditionally. This aligns the nvidia-container-cli path — used by docker --gpus without the nvidia runtime — with that behavior.

Resolution

The modeset device mount condition in nvc_mount.c checks OPT_DISPLAY|OPT_GRAPHICS_LIBS instead of OPT_DISPLAY alone, with the comment updated accordingly.

Reviewer Considerations

• After this change, graphics and display are functionally identical in this library since OPT_DISPLAY gates nothing else. This is intentional and matches the toolkit's OCI-level behavior and CDI semantics.
• load_kernel_modules() already loads nvidia_modeset and creates the device node under --load-kmods, so no creation-side change is needed.
• The WSL path is unaffected: the check sits inside the !dxcore.initialized branch.

Behavior Changes

• Containers requesting graphics without display receive the modeset device mount and its device cgroup entry.
• compute, utility, and video remain unchanged; display behavior is unchanged.

Implementation Summary

• Extend one condition and its comment in the device mount loop in nvc_mount.c.

Verification

• Built shared and tools on Ubuntu x86_64 with GCC 14 (WITH_LIBELF=yes WITH_TIRPC=yes, version and revision provided for a tag-less tree).
• A/B validation on 2x Tesla P100, driver 580.178.04, Docker 29.7.2, with the CDI spec removed so docker run --runtime=runc --gpus all exercises the hook path and the host node deleted before each run:
  • stock library, NVIDIA_DRIVER_CAPABILITIES=graphics: no modeset device in the container;
  • patched library, graphics: /dev/nvidia-modeset present and openable, with the host node created by --load-kmods;
  • compute,utility: no modeset device; display: unchanged.

[Copilot]

Pull request overview

This PR aligns nvidia-container-cli’s device injection behavior with the NVIDIA Container Toolkit’s OCI-level semantics by ensuring /dev/nvidia-modeset is mounted for containers that request either the display or graphics capability (previously only display).

Changes:

• Extend the modeset-device gating check in nvc_driver_mount() to allow provisioning when OPT_GRAPHICS_LIBS is set, not only OPT_DISPLAY.
• Update the in-code comment to reflect the expanded gating condition.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[henry118]

/ok to test 43ec8ca

[henry118]

what's the rational for this change? I'm not sure if it's necessary for the purpose of this PR.

[ehfd]

The old code hard-coded the modeset entry: modeset.id = makedev(NV_DEVICE_MAJOR, NV_MODESET_DEVICE_MINOR); has_modeset = 1; so /dev/nvidia-modeset was listed unconditionally, even when the node doesn't exist on the host (i.e. the nvidia-modeset kernel module isn't loaded). Using find_device_node makes the entry conditional on the device actually being present: it stats the node and warn-and-skips on ENOENT instead of registering a device that would later fail to mount, and it records the real st_rdev rather than assuming the fixed major/minor. It also matches how nvidia-uvm and nvidia-uvm-tools are discovered in the same function, just above.

So, it's a sanity fix that closes a real source of failure.

/dev/nvidia-modeset is a userspace-created device, like /dev/nvidia-uvm or /dev/nvidia-uvm-tools. It should work identically.

[ehfd]

Full code around the edit location:

        else {
                if (!(flags & OPT_NO_UVM)) {
                        if ((has_uvm = find_device_node(err, root, NV_UVM_DEVICE_PATH, &uvm)) < 0)
                                return (-1);
                        if ((has_uvm_tools = find_device_node(err, root, NV_UVM_TOOLS_DEVICE_PATH, &uvm_tools)) < 0)
                                return (-1);
                }
                if (!(flags & OPT_NO_MODESET)) {
                        if ((has_modeset = find_device_node(err, root, NV_MODESET_DEVICE_PATH, &modeset)) < 0)
                                return (-1);
                }
                nvidiactl.path = (char *)NV_CTL_DEVICE_PATH;
                nvidiactl.id = makedev(NV_DEVICE_MAJOR, NV_CTL_DEVICE_MINOR);
                has_nvidiactl = 1;
        }