Re: [PATCH 3/8] rust: pci: add {enable,disable}_sriov(), to control SR-IOV capability

[Peter Colberg]

Hi Jason,

On Mon, Jan 05, 2026 at 09:22:36PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 23, 2025 at 02:17:12PM -0500, Peter Colberg wrote:
> > Further, enable_sriov() is prevented during remove() using a new
> > flag inhibit_enable in the pci_sriov structure that is set before
> > and cleared after the PF driver is unbound from the device.
> 
> Doesn't this need something concurrent safe like a revocable?

Thank you for the follow-up and apologies for the delay. I have now
posted a v2 series that takes a different approach from what was
described earlier, after discussing this further with Danilo.

In the v2 patch [1], when the new PCI driver flag managed_sriov is
set, which is always the case for Rust, SR-IOV is disabled twice if
needed: once before the unbind() callback for a well-behaved driver,
and a second time after unbind() for a broken (but nevertheless using
safe APIs only) driver that re-enables SR-IOV during unbind().

Together with commit a995fe1a3aa7 ("rust: driver: drop device private
data post unbind") which ensures that the device private data for the
PF device is still alive until after the function pci_iov_remove() is
called and forcibly re-disables SR_IOV if needed, this upholds the
safety guarantee which pci::Device::physfn() depends on.

As an alternative for preventing SR-IOV management during unbind(), I
briefly considered adding a new context, e.g., CoreInternal => Core =>
CoreUnbind => Bound => Normal, where {enable,disable}_sriov() are
implemented by Core but not CoreUnbind, but discarded that solution
since it seems too specific to this case to warrant the complexity.

Thanks,
Peter

[1] https://lore.kernel.org/rust-for-linux/20260205-rust-pci-sriov-v2-1-ef9400c7767b@xxxxxxxxxx/

> 
> Jason
>