linux-kernel - Re: [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't support VFs

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: <20251002135600.GB3266220@nvidia.com>
Date: Thu, 2 Oct 2025 10:56:00 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: John Hubbard <jhubbard@...dia.com>,
	Alexandre Courbot <acourbot@...dia.com>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Timur Tabi <ttabi@...dia.com>, Alistair Popple <apopple@...dia.com>,
	Zhi Wang <zhiw@...dia.com>, Surath Mitra <smitra@...dia.com>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Alex Williamson <alex.williamson@...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>,
	nouveau@...ts.freedesktop.org, linux-pci@...r.kernel.org,
	rust-for-linux@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't
 support VFs

On Thu, Oct 02, 2025 at 03:03:38PM +0200, Danilo Krummrich wrote:

> I think it's not unreasonable to have a driver for the PF and a separate driver
> for the VFs if they are different enough; the drivers can still share common
> code of course.

This isn't feasible without different PCI IDs. ICE does this for
example where they have two totally different drivers, and of course
two different PCI IDs.

> Surely, you can argue that if they have different enough requirements they
> should have different device IDs, but "different enough requirements" is pretty
> vague and it's not under our control either.

If you want two drivers in Linux you need two PCI IDs.

We can't reliably select different drivers based on VFness because
VFness is wiped out during virtualization.

> But, if there is another solution for VFs already, e.g. in the case of nova-core
> vGPU, why restrict drivers from opt-out of VFs. (In a previous reply I mentioned
> I prefer opt-in, but you convinced me that it should rather be
> opt-out.)

I think nova-core has a temporary (OOT even!) issue that should be
resolved - that doesn't justify adding core kernel infrastructure that
will encourage more drivers to go away from our kernel design goals of
drivers working equally in host and VM.

Nova core should work in that it probes, detects an unprovisioned VF
and then fails probe. This edge case could perhaps arise in a VM
anyhow and needs to be handled anyhow.

Also, this is all pointless until nova-core gets an sriov_configure
callback - you can't even turn on SRIOV without that!

Jason