linux-kernel - Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core

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: <ac350595-665f-46a1-aca5-167c5648337c@nvidia.com>
Date: Wed, 1 Oct 2025 15:35:32 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>,
 Alex Williamson <alex.williamson@...hat.com>
Cc: Alexandre Courbot <acourbot@...dia.com>,
 Danilo Krummrich <dakr@...nel.org>, 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>,
 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 0/2] rust: pci: expose is_virtfn() and reject VFs in
 nova-core

On 10/1/25 11:30 AM, Jason Gunthorpe wrote:
> On Wed, Oct 01, 2025 at 12:16:31PM -0600, Alex Williamson wrote:
>> I think the question would be whether a "bare" VF really provides a
>> useful device for nova-core to bind to or if we're just picking it
>> up
> 
> It really should work, actual linux containers are my goto reason for
> people wanting to use VF's without a virtualization layer.

This is a solid use case, even though we don't yet have it for GPUs.

> 
>> fair bit of software emulation/virtualization in the host vGPU driver to
>> turn the VF into something that can work like a PF in the VM and I
>> don't know that we can require nova-core to make use of a VF without
>> that emulation/virtualization layer.  For example, aren't VRAM
>> allocations for a VF done as part of profiling the VF through the vGPU
>> host driver? 
> 
> The VF profiling should be designed to work without VFIO.

So we'll need to add some support to nova-core, in order for that to
happen. It's not there yet, of course.

> 
> It is was one thing to have the VFIO variant driver profile mediated
> devices that only it can create, but now that it is a generic VF
> without mediation it doesn't make sense anymore.
> 
> The question is how much mediation does the variant driver insert
> between the VM and the VF, and from what I can see that is mostly
> limited to config space..
> 
> IOW, I would expect nova-core on the PF has a way to profile and
> activate the VF to a usable state and then nova-core can run either
> through a vm or directly on the VF.
> 
> At least this is how all the NIC drivers have their SRIOV support
> designed today.
> 

OK, so I really like this design direction, and we can go in that 
direction.

However, I'd like to start with this tiny patchset first, because:

a) It's only one "if" statement to delete, when we decide to start
letting nova-core support VFs directly.

b) This series simplifies handling of VFs for the first use case,
which is vGPU running on VFIO.


thanks,
-- 
John Hubbard