Re: [PATCH 7/8] rust: pci: add physfn(), to return PF device for VF device

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Nov 23, 2025 at 01:18:23PM +0200, Leon Romanovsky wrote:
> > >> That sounds a bit odd to me, what exactly do you mean with "reuse the PF for
> > >> VFIO"? What do you do with the PF after driver unload instead? Load another
> > >> driver? If so, why separate ones?
> > >
> > > One of the main use cases for SR-IOV is to provide to VM users/customers
> > > devices with performance and security promises as physical ones. In this
> > > case, the VMs are created through PF and not bound to any driver. Once
> > > customer/user requests VM, that VF is bound to vfio-pci driver and
> > > attached to that VM.
> > >
> > > In many cases, PF is unbound too from its original driver and attached
> > > to some other VM. It allows for these VM providers to maximize
> > > utilization of their SR-IOV devices.
> > >
> > > At least in PCI spec 6.0.1, it stays clearly that PF can be attached to SI (VM in spec language).
> > > "Physical Function (PF) - A PF is a PCIe Function that supports the SR-IOV Extended Capability
> > > and is accessible to an SR-PCIM, a VI, or an SI."
> > 
> > Hm, that's possible, but do we have cases of this in practice where we bind and
> > unbind the same PF multiple times, pass it to different VMs, etc.?
> 
> It is very common case, when the goal is to maximize hardware utilization.

It is a sort of common configuration, but VFIO should be driving the
PF directly using its native SRIOV support. There is no need to rebind
a driver while SRIOV is still enabled.

> > You're mixing two things here. The driver model lifecycle requires that if
> > driver A calls into driver B - where B accesses its device private data - that B
> > is bound for the full duration of the call.
> 
> I'm aware of this, and we are not talking about driver model. Whole
> discussion is "if PF can be unbound, while VFs exist". The answer is yes, it can,
> both from PCI spec perspective and from operational one.

This whole discussion highlights my original feeling.. While I think
it makes alot of sense to tie the VF lifecycle to the PF driver
binding universally there are enough contrary opinions.

> > At least conditionally (as proposed above), it's an improvement for cases where
> > there is PF <-> VF interactions, i.e. why let drivers take care if the bus can
> > already do it for them.

Drivers like mlx5 have a sequencing requirement during shutdown, it
wants to see SRIOV turned off before it moves on to other steps. This
is probably somewhat common..

So while it is nice for the bus to guarentee it, it probably also
signals there is a bug somewhere if that code gets used..

Jason