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

["Danilo Krummrich" <dakr@kernel.org>]

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.

Thanks,
Danilo