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: <DD7UVCEVB21H.SQ00WZLLPINP@kernel.org>
Date: Thu, 02 Oct 2025 15:03:38 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Jason Gunthorpe" <jgg@...dia.com>
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 2, 2025 at 2:39 PM CEST, Jason Gunthorpe wrote:
> On Thu, Oct 02, 2025 at 02:18:36PM +0200, Danilo Krummrich wrote:
>> On Thu Oct 2, 2025 at 2:11 PM CEST, Jason Gunthorpe wrote:
>> > On Wed, Oct 01, 2025 at 07:00:09PM -0700, John Hubbard wrote:
>> >> Add a "supports_vf" flag to struct pci_driver to let drivers declare
>> >> Virtual Function (VF) support. If a driver does not support VFs, then
>> >> the PCI driver core will not probe() any VFs for that driver's devices.
>> >> 
>> >> On the Rust side, add a const "SUPPORTS_VF" Driver trait, defaulting to
>> >> false: drivers must explicitly opt into VF support.
>> >
>> > As I said in the other thread - please no.
>> >
>> > Linux drivers are expected to run on their VFs.
>> 
>> The consequence would be that drivers for HW that can export VFs would need to
>> be rejected upstream if they only support the PF, but no VFs. IMHO, that's an
>> unreasonable requirement.
>
> Not rejected, they just need to open code a simple isvf check and fail
> during probe if they really have a (hopefully temporary) problem.

The question is whether it is due to a (temporary) problem, or if it is by
design.

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.

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.

> This not really a realistic case. Linux running in the VM *should*
> have drivers that operate the VF, and those existing drivers *should*
> work in the PF context.
>
> Drivers that work in VM but not in a host should not be encouraged!!

I agree, we should indeed encourage HW manufacturers to design the HW in a way
that a single driver works in both cases, i.e. less less code to maintain, less
surface for bugs, etc., if that is what you mean.

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.)

> AFAICT this is even true for novacore, the driver should "work" but
> the VF won't be provisioned today so it should fail startup in some
> way. eg "no vram" or something like that.
>
>> > This temporary
>> > weirdness of novacore should not be elevated to a core behavior that
>> > people will misuse.
>> 
>> It's not just nova-core, please see [1].
>> 
>> [1] https://lore.kernel.org/lkml/DD7TP31FEE92.2E0AKAHUOHVVF@kernel.org/
>
> I responded there, I don't think the reasons those were added to ICE
> and then cargo-culted are very good, not good enough to justify adding
> it to the core code.

Indeed, the justification of ICE is clearly wrong.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ