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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251124150450.GS233636@ziepe.ca>
Date: Mon, 24 Nov 2025 11:04:50 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Leon Romanovsky <leon@...nel.org>
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 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.

Jason