Re: [PATCH 00/14] Add Rust PCI SR-IOV support

[Danilo Krummrich]

On Tue Sep 15, 2026 at 10:56 PM CEST, Zhi Wang wrote:
> Rust PCI drivers need to enable and disable SR-IOV and share selected
> PF-owned functionality with their VF drivers. The shared data must remain
> valid while a VF driver is bound, including when the VF driver is in C.
>
> This series builds on Peter Colberg's Rust PCI SR-IOV v3 series [1],
> extending it with typed PF registration data and C FFI support. The
> registration design follows Danilo Krummrich's Rust vGPU/VFIO PoC [2].
> As the discussion on Rust/VFIO support is still ongoing [3], this series
> supports both C and Rust sample VF drivers.

[...]

> [1] https://lore.kernel.org/rust-for-linux/20260303-rust-pci-sriov-v3-0-4443c35f0c88@xxxxxxxxxx/
> [2] https://lore.kernel.org/nova-gpu/DLCRZLO06SIO.LS7TWQXIPZSQ@xxxxxxxxxx/
> [3] https://lore.kernel.org/nova-gpu/20260914121217.70fa0d93@xxxxxxxxxxx/
>
>  drivers/pci/iov.c                        | 103 ++++++-
>  drivers/pci/pci-driver.c                 |   3 +-
>  drivers/pci/pci.h                        |   2 +
>  include/linux/pci.h                      |  44 +++
>  include/linux/rust_ffi.h                 |  88 ++++++
>  rust/kernel/interop/ffi.rs               | 252 ++++++++++++++++
>  rust/kernel/pci.rs                       | 126 ++++++++
>  rust/kernel/pci/sriov.rs                 | 355 +++++++++++++++++++++++
>  rust/macros/ffi_vtable.rs                | 148 ++++++++++
>  rust/macros/lib.rs                       |  90 ++++++

Thanks for all the effort, Zhi! It is good to have a reference to see how this
turns out.

Unfortunately, this raises the same concerns I already shared in the other
thread in [2], plus additional ones:

  (1) This FFI layer is already more code than would be needed to abstract the
      vfio-pci driver API surface in Rust. In addition, it is also much more
      complex and error prone.

  (2) By creating a generic FFI layer to connect PF and VF drivers (which are
      technically the same driver project), we incentivise writing cross
      language drivers.

      When the panthor DRM driver was considering to (re-)write parts in Rust I
      very much objected to this, as it would have created an arbitrary FFI
      boundary within DRM (which for obvious reasons would be a maintainance
      nightmare).

      Now, this is not exactly the same, as it is not an arbitrary FFI boundary;
      it is well defined. But, it is still a workaround for a single driver
      project being split up in a Rust and in a C portion.

      The FFI surface is best kept at the subsystem level abstracting the driver
      facing APIs, which provides a defined and comparatively stable API
      surface.

For those reasons I don't want to add this to the PCI (Rust and C) core code,
i.e. I don't want to support a generic FFI layer between PF and VF drivers.

I really hope that we can find a way forward not having to end up doing this;
but if we really have to, we should stick to a nova project internal FFI layer
for this.

Thanks,
Danilo