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

[Alex Williamson]

On Thu, 17 Sep 2026 22:09:58 +0200
"Danilo Krummrich" <dakr@xxxxxxxxxx> wrote:

> On Thu Sep 17, 2026 at 7:10 PM CEST, Jason Gunthorpe wrote:
> > 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.  
> 
> I can assure you we can set this concern aside. The driver core code, auxiliary,
> platform, PCI, DMA, scatterlist, DRM, firmware loader, IRQ, I/O and fwctl, to
> name just a few, did not need any changes. And from the top of my head I can't
> think of any case where changes were needed.
> 
> For VFIO I already wrote the code, and no changes were required either, except
> for the drvdata things of course.
> 
> But, as discussed, this is an existing layering violation. The Rust driver code
> code simply relies on its own subsystem's API contract. Please let's not frame
> this as a Rust issue.
> 
> Plus, it is trivial to address, so it luckily is not a huge problem anyway. :)
> 
> >> 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?  
> 
> If a new C driver is not affected the Rust abstraction won't be affected either.
> They are just users of the same APIs the C drivers consume. So, that doesn't
> seem to be a concern then.
> 
> >> > 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.  
> 
> The same would then be true for an nvidia-vgpu driver written in C, no? Again,
> the Rust abstractions are nothing else than a driver in the end. They only
> consume the driver facing APIs and translate them to a safe Rust API.
> 
> > And then we end up with what will be one of the most complex drivers
> > in a form nobody familiar with vfio can review.  
> 
> I think this isn't the case; the people you refer to can still review semantics
> and vfio design specifics. It's not like everything is different.
> 
> For instance, there's still a get_region_info() callback on
> vfio::pci::Operations where people can review whether this semantically makes
> sense.
> 
> And for the language specifics we have a lot of Rust familiar people around who
> will review the code and help to improve it.
> 
> Why not see this as a chance to scale on both ends? More people on both ends
> will get familiar with VFIO and Rust at the same time.

This thread has gone cold for a few days and nothing really seems to be
dissuading from the direction of implementing the Nova interfacing
vfio-pci variant vGPU driver in Rust.  Zhi has been investigating the
gaps and bugs in the PoC, and afaik, nothing stands out as a blocker.

I'll do my best to use LLM assisted reviews on my part, but the
expectation should be that I won't be merging any Rust code without
formal reviews on list.  Over time I hope to be able to contribute from
that perspective, but the Rust community is going to need to hold their
end of the bargain as well.  If meaningful reviews are not provided,
the driver can be orphaned and removed.

The Rust community also needs to be proactive in supporting the vfio
community such that abstractions and interfaces between C and Rust
don't become a barrier for C-based development.  Keeping the Rust code
working when the C code changes is the Rust community's job, we
shouldn't expect more than "best effort" from the existing C-focused
community.

I also want to be clear, I'm not endorsing Rust as a pattern anywhere
beyond this individual vfio-pci variant driver.  Any other proposals
would need to bring a comparably sized community to sponsor them.

Dave's approach to make vfio-pci-core a stateless helper with respect
to drvdata, with a dash of Jason's macro idea to minimize the driver
boilerplate for the common cases, seems like the right direction to
remove that convention.  I've handed off my own LLM generated version
that does this and it should be refined and posted soon.

So, unless there's an aspect we haven't considered, it seems the Rust
variant driver should be the direction here.  Thanks,

Alex