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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251124145332.GB12483@unreal>
Date: Mon, 24 Nov 2025 16:53:32 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Danilo Krummrich <dakr@...nel.org>, Peter Colberg <pcolberg@...hat.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Abdiel Janulgue <abdiel.janulgue@...il.com>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Robin Murphy <robin.murphy@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dave Ertman <david.m.ertman@...el.com>,
	Ira Weiny <ira.weiny@...el.com>, linux-pci@...r.kernel.org,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alexandre Courbot <acourbot@...dia.com>,
	Alistair Popple <apopple@...dia.com>,
	Joel Fernandes <joelagnelf@...dia.com>,
	John Hubbard <jhubbard@...dia.com>, Zhi Wang <zhiw@...dia.com>
Subject: Re: [PATCH 7/8] rust: pci: add physfn(), to return PF device for VF
 device

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