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

[Alex Williamson <alex@shazbot.org>]

Hi Danilo,

On Fri, 11 Sep 2026 22:39:16 +0200
"Danilo Krummrich" <dakr@kernel.org> wrote:

> Hi Alex, Jason, Zhi,
> 
> On Sat Sep 5, 2026 at 10:11 AM CEST, Zhi Wang wrote:
> > NVIDIA vGPU VFs require their open, reset, and close lifecycle to be
> > coordinated with the PF-side nova-core driver.  
> 
> [...]
> 
> >  drivers/vfio/pci/nvidia-vgpu/main.c   | 253 ++++++++++++++++++++++++++  
> 
> This is going to be a longer response; sorry about this in advance.
> 
> Looking at the FFI boundary introduced in the previous patch, I'm concerned that
> it translates the driver model relationships we've expressed through Rust's
> ownership and lifetime model back into raw pointers and lifetime assumptions
> that callers must uphold. It also introduces manual lifecycle management across
> the boundary, rather than preserving nova-core's RAII-based ownership model.
> 
> I think implementing the NVIDIA vGPU driver in Rust would let us preserve those
> relationships across the interface, make lifecycle management less error-prone,
> and fit naturally alongside nova-core and nova-drm.
[snip]
> 
> If you've made it this far, thanks for reading through this long write-up. I
> hope you find it useful. Please let me know if you have any questions or
> thoughts.

I can't really say I made it this far with comprehension, but thanks
for the effort ;)

The one piece here that I can actually review is [5], where
dev_get_drvdata() is replaced with a vfio-pci-core struct pointer
embedded in the struct pci_dev, which is a non-starter as far as having
a common PCI-core shared by various drivers.

Maybe Dave Airlie can share some experience here with a Rust driver
growing up within a subsystem for a non-Rust-literate maintainer.

My concerns are of course who is going to review the Rust vfio-pci
variant drivers from a vfio perspective, not just a drm driver
viewpoint.  Who is going to be responsive when the interfaces break and
monitor vfio proactively to prevent such breakages, and how do we avoid
derailing feature development in the core code base.  Can a Rust
vfio-pci variant driver be self-contained, or to what extent does it
impose on the framework, such as the drvdata idiom.

FWIW, AI can only go so far to support reviews.  Having the code
insight to ask the right questions is essential.  A human in the loop
is a requirement.

Additionally, if we can't narrow the device matching to only the
Nova-core supported VFs, then this variant driver must immediately
provide feature parity of vfio-pci with pass-through to vfio-pci-core
for matched devices.  Libvirt selects a best matching variant driver by
modalias with our override scheme.

I'd also like to hear from other core vfio contributors.  Thanks,

Alex


> [1] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/log/?h=poc/vgpu
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/commit/?id=484316d855e3d61873122c295feb9a7457eeca21
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/commit/?id=6292c1de7f0758dd31496a454b4034507f38bd40
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/commit/?id=efac2cec97eab36edd01a2fe79aea67a04bd8842
> [5] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/commit/?id=76b3bfd6386a01f338780e1a37b5bad3f5a48d31
> [6] https://lore.kernel.org/lkml/20260303-rust-pci-sriov-v3-1-4443c35f0c88@redhat.com/