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

[Leon Romanovsky <leon@kernel.org>]

On Mon, Nov 24, 2025 at 09:57:25AM -0400, Jason Gunthorpe wrote:
> 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.

It depends on how you created these VFs. If you created them through
native driver, you will need to unbind and bind it to VFIO.

Thanks