Question: Is it no longer possible to disable GSP with open kernel modules (v530.41.03)?

[asdfank]

Hello team,

I have a question regarding the GSP firmware behavior with the open-source kernel modules. I am trying to disable GSP, but it appears to remain active. I would like to confirm if this is the intended behavior.

My Environment:

• GPU: NVIDIA GeForce RTX 4060 Laptop GPU
• Driver Version: 530.41.03 (Open Source Kernel Modules)
• OS: Debian 11 (Bullseye)
• Kernel Version: Linux 6.2

Steps I took to disable GSP:

1. I created a modprobe configuration file:

   echo "options nvidia NVreg_EnableGpuFirmware=0" | sudo tee /etc/modprobe.d/nvidia-gsp.conf

2. I updated the initramfs:

   sudo update-initramfs -u

3. After rebooting, I verified that the kernel parameter was loaded:

   cat /proc/driver/nvidia/params | grep EnableGpuFirmware

   The output correctly shows: NVreg_EnableGpuFirmware: 0

Observed Outcome:

Despite the kernel parameter being set to 0, nvidia-smi still reports a GSP firmware version, suggesting GSP is active:

nvidia-smi -q | grep "GSP Firmware"

Output: GSP Firmware Version                  : 530.41.03

My Question:

I noticed this line in the README.md for the driver:

Note that the kernel modules built here must be used with GSP firmware...

Does this mean that GSP has become a mandatory component for the open kernel modules starting from this version (or earlier), and the NVreg_EnableGpuFirmware=0 parameter no longer disables it?

I would appreciate it if you could clarify whether this is the expected behavior.

Thank you for your excellent work on the open-source drivers!

[mtijanic]

Hi there. GSP has always been a requirement of the open kernel modules, and this parameter never did anything here. The reason the parameter even exists on the open kernel modules is because folks like to switch between open and proprietary and often have this param set (to either 0 or 1) somewhere, and the kernel will (rightly) complain if you try to set an invalid param, so it is just ignored. Maybe we should add a dmesg print that says it is ignored?

You can still disable GSP on the proprietary flavor of the kernel modules, but note that most of our development and testing resources are spent on the GSP-enabled configurations.

[asdfank]

Thank you very much for the prompt and incredibly clear explanation. It perfectly answers my question and clears up all my confusion.

I appreciate you taking the time to elaborate on this!

[asdfank]

收到

[arisu3]

My understanding is that the GSP's purpose (among other things) is to hide certain functionality from the end-user to make reverse engineering and research harder. Previously, a lot of GPU control functionality was being handled by the driver, but there's only so much obfuscation that can be done there. So instead a lot of that functionality is put in the GSP so that it functions as a black box.

The open kernel modules have removed all of this control code, so if you disabled the GSP you just couldn't use the GPU at all. Some lawyer probably said "you can't let your customers know too much about your product" and the solution was to move the functionality into a dedicated coprocessor instead of giving up on any possibility of an open driver.

It's not like Nvidia is unique in doing this. A lot of devices will use binary blobs that are loaded directly onto the device so that they can open some, but not all, of their code without violating any licenses. What is unique is that Nvidia has an option to either use the binary blob (for their GSP) or perform the same functionality in the (closed) driver.

[asdfank]

收到

[arisu3]

There is no need to have a bot reply that you've received the message, btw. ;)