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

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Sep 17, 2026 at 04:50:07PM +0200, Danilo Krummrich wrote:
> On Thu Sep 17, 2026 at 3:28 PM CEST, Jason Gunthorpe wrote:
> > On Wed, Sep 16, 2026 at 08:02:17PM +0200, Danilo Krummrich wrote:
> >> >> 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..
> >> 
> >> So it seems that we agree that there isn't really a difference between adding a
> >> new C or Rust driver in this regard.
> >
> > To be clear I was trying to say I think you are are underestimating
> > how much work this is and how long it will take. Including all the
> > preconditon C reworks has to be included when considering how much
> > work is involved.
> 
> I'm not sure I follow what you mean by "preconditon C reworks".

Rust bindings often seem to need C code rework for Rust, drvdata here
is an example.

> Or do you refer to other C core reworks people are working on? If so, they are
> only relevant if they affect the drivers. And if they affect the drivers,
> there's not really a difference between adding a new C driver and adding a Rust
> abstraction.

A new C driver should not need reworks?

> > I cannot forsee rust bindings for vfio until sometime in 2027.
> 
> What is different in 2027 than is now?

I mean I think that is how long it will take to merge something like
that, given how many other vfio series there are, the lack of
expertise, and some general expectations. There are already lots of
series for vfio that are in front of something like this in the queue.

And then we end up with what will be one of the most complex drivers
in a form nobody familiar with vfio can review.

It just seems like a much bigger thing to me than whatever the ffi
problem is..

Jason