Re: [PATCH 2/2] gpu: nova-core: add fwctl driver for firmware control interface

[Gary Guo]

On Mon Mar 30, 2026 at 7:18 PM BST, Jason Gunthorpe wrote:
> On Mon, Mar 30, 2026 at 01:42:07PM -0400, Joel Fernandes wrote:
>
>> Just trying to confirm my understanding: Doesn't that mean
>> NV2080_CTRL_CMD_VGPU_MGR_INTERNAL_PGPU_ADD_VGPU_TYPE becomes a part of UAPI
>> then?
>
> Yes.

I think it is probably undesirable for nova-core to expose GSP firmware detail
to userspace directly.

>
>> On the one hand, there is the argument that userspace should not
>> deal with GSP-RM specific commands directly (lest they change in the
>> future or get removed or whatever, and nova-core is the
>> abstraction. On the other hand, I think idea behind fwctl is as
>> Jason put it above. So which path is correct and makes sense for
>> nova-core?
>
> If you use fwctl it should be as I described, it is not an generic
> interface to send SW command to the kernel, the commands have to be
> delivered to FW.

If fwctl isn't designed to provide abstraction layer between userspace/FW and is
for raw access only, then an alternative mechanism should be used instead.

The cover letter says this:

> This series adds a fwctl driver to nova-core, enabling userspace to issue
> firmware commands to the GSP through the standard fwctl ioctl
> interface. E.g. uploading the vGPU type blobs and managing the vGPU
> lifecycle, which is previously implemented in sysfs.

Zhi, is there a reason that sysfs is undesirable interface for this?

Best,
Gary

>
>> These are transport-layer headers for the GSP RPC message queue, MCTP provides
>> packet framing (it is a standard protocol like networking protocols) and NVDM is
>> NVIDIA specific header carried inside MCTP. IMO they are internal to the
>> nova-core <-> GSP transport and should be filled in by the kernel driver, not
>> exposed to userspace.
>
> That makes more sense to me. I would expect only the actual payload to
> be part of fwctl. Any transport details must be managed by the kernel.
>
> Jason