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

[Jason Gunthorpe]

On Wed, Sep 16, 2026 at 05:38:21PM +0200, Danilo Krummrich wrote:
> Usually, class device implementations can't make assumptions of the underlying
> bus, because they have to work for any bus. I.e. there's no other way than
> providing helpers and letting drivers do the glue code between the bus and the
> class device.

You should think of VFIO as a series of helper libraries. One of those
libraries is "here are all the PCI PM ops you need".

Drivers rarely need to customize these ops, they just need to wire it
up to the support library to avoid a bunch of code duplication.

Stated another way - the very point of vfio-pci is to remove
duplicated code from the drivers.

So if we wanted to push hard on removing drvdata, and don't want to
touch the struct device I would probably say to #define up a way for
the driver to build its unique trampolines. It wastes a bunch of .text
but at least it doesn't duplicate code.

> The reason this seems undesirable from a vfio-pci perspective is that it is
> special in the sense that it is a class device that is specifically built to sit
> on top of a spcific bus device (i.e. struct pci_dev).

It is a library, all these ideas to do things with the driver core to
implement a library make no architectural sense.

> It still makes me think that there should be some closer integration of vfio-pci
> with the PCI core, as it is specifically built for this bus.

It has such a basic need I don't see this as a reason to pollute pci
core with any vfio specific things. Like I would nak your [1], that's
completely wrong layering.

> > 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?
> 
> I mentioned some points in the first two paragraphs of [2]. Besides that, I
> don't see a reason why we should spend time and effort for working out the
> inferior solution, where the better alternative is even less effort, contributes
> to better quality and stability of the whole driver project and also offers a
> chance for the vfio subsystem to gain new contributors and gather experience
> with the language that has proven itself in many areas already.

It seems to be quite a leap that it is less effort. IDK..

> TBH, I don't think it makes a difference; having Rust abstractions is pretty
> much the same as having another driver. I.e. it would be equivalent to saying
> "before we accept another pci-vfio driver we need to do some rework".

Well, it is, but thats the point when judging effort..

Jason