Re: [PATCH 12/13] vfio/nvidia-vgpu: add the NVIDIA vGPU VFIO variant driver

[Jason Gunthorpe]

On Tue, Sep 15, 2026 at 11:19:01PM +0200, Danilo Krummrich wrote:

> The driver_data pointer in struct device is defined to be a pointer where a
> driver can store *arbitrary* data for the duration the driver is bound to this
> device.

There are places in the kernel where the drvdata of the bound device
ends up owned by the subsystem, not the end driver.  Yes, an ideal
driver + subsystem should never even need drvdatab beyond remove. Yet,
things are not perfect..

The fundamental issue is some kernel API surfaces that the subystem
needs to work with only provide a struct device in their callbacks and
the subystem has no option but to use the drvdata for its own purpose
to recover the subsystem specific data.

For example VFIO hooks into this nasty API:

        ret = vga_client_register(pdev, vfio_pci_set_decode);
        if (ret)
                return ret;

Which doesn't provide a void * token to pass the core code's
struct. 

Another is all the PCI callbacks which assume the op behind them uses
drvdata to get its data.

It is not necessarily easy to fix. Rrouting all those PCI callbacks
through trampolines in every single driver is really not an appealing
design. There are alot of VFIO drivers.

Maybe it needs a dev->drvdata and dev->subsystem_data, maybe it needs
some PCI thing where the pm ops can get a void *, IDK.

This is not some philosophical thing about busses or classes, it is
just an accommodation for the way the kernel is now. Fix the above and
you can get rid of it.

> > I have no doubt that integration with a more structured language would
> > lead to various improvements.  However, it doesn't seem there are
> > resources to support it in the short term.
> 
> As mentoined above, there are people volunteering now. Without starting it, it
> can't scale further than that. :)

There are lots of other vfio patches that need attention too, and it
seems we are short of that more than anything. Now you need to do a
bunch of C refactoring patches as well just to get things ready to
show a bunch of rust code. It is a lot of work.

I don't really understand in a nutshell why we should do this for nova
the mails were so long... Can we not just ignore the lifetime
imperfection for this?

> However, I don't really see the use-case; you can't load nvidia-vgpu without
> nova-core in the first place, so it would require to unbind nova-core through
> sysfs force unbind, no?

nvidia gpu is a more unique scenario, if you are building a general
bindings it has to support the flows like this.

I've wanted to rework the way the common ops are shimmed in for a
while, you'd probably want to do that before rust bindings.

Jason