Rust PCI drivers get a proposed path to SR-IOV

Simon Song has posted a sixth revision of patches that would let Rust PCI drivers turn on Single Root I/O Virtualization and share selected physical-function data with virtual-function drivers until those functions are fully gone.

SR-IOV splits one PCI device into a physical function and virtual functions that can be handed to guests or other drivers. Rust bindings already cover ordinary PCI probe and remove. They still lack a typed way to configure virtual functions and to keep physical-function state alive for the drivers bound to them. Without that, a virtual-function driver can outlive the data it needs, or a failed setup can leave virtual functions enabled.

The series, which builds on earlier work by Peter Colberg and a registration design from Danilo Krummrich, splits enable and disable into paired callbacks. Enabling returns a guard that turns the functions back off if later setup fails. Once enable succeeds, a registration object owns the final teardown: it disables SR-IOV and waits for virtual-function removal before the shared object is dropped. Drivers that do not share data can register an empty payload. When SR-IOV is compiled out, the API is stubbed rather than hidden behind configuration checks, so driver code does not need its own guards.

One ordering change is specific to VFIO. Rust driver data is normally dropped after the PCI remove callback returns. VFIO's unregister path expects to run from that callback, so the series drops PCI driver data before remove returns. Song's cover note treats that as a special case, not a general rule for other drivers.

A sample physical-function and virtual-function pair, built as one module and exercised against QEMU's 82576 emulation, shows the shared-data lookup. Bjorn Helgaas has acknowledged the small C-side slot that holds the registration pointer. The patches are still under review and have not been merged.