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 11:04:50AM -0400, Jason Gunthorpe wrote:
> On Mon, Nov 24, 2025 at 04:53:32PM +0200, Leon Romanovsky wrote:
> > 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.
> 
> That should not be done or encouraged.

Maybe, but this is how it is done now.

Thanks

> 
> Jason