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: <20251001144629.GA3024065@nvidia.com>
Date: Wed, 1 Oct 2025 11:46:29 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: John Hubbard <jhubbard@...dia.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>,
	Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in
 nova-core

On Tue, Sep 30, 2025 at 06:26:23PM -0700, John Hubbard wrote:
> On 9/30/25 5:26 PM, Alexandre Courbot wrote:
> > On Wed Oct 1, 2025 at 7:07 AM JST, John Hubbard wrote:
> >> Post-Kangrejos, the approach for NovaCore + VFIO has changed a bit: the
> >> idea now is that VFIO drivers, for NVIDIA GPUs that are supported by
> >> NovaCore, should bind directly to the GPU's VFs. (An earlier idea was to
> >> let NovaCore bind to the VFs, and then have NovaCore call into the upper
> >> (VFIO) module via Aux Bus, but this turns out to be awkward and is no
> >> longer in favor.) So, in order to support that:
> >>
> >> Nova-core must only bind to Physical Functions (PFs) and regular PCI
> >> devices, not to Virtual Functions (VFs) created through SR-IOV.
> > 
> > Naive question: will guests also see the passed-through VF as a VF? If
> > so, wouldn't this change also prevents guests from using Nova?
> 
> I'm also new to this area. I would expect that guests *must* see
> these as PFs, otherwise...nothing makes any sense.
> 
> Maybe Alex Williamson or Jason Gunthorpe (+CC) can chime in.

Driver should never do something like this.

Novacore should work on a VF pretending to be a PF in a VM, and it
should work directly on that same VF outside a VM.

It is not the job of driver to make binding decisions like 'oh VFs of
this devices are usually VFIO so I will fail probe'.

VFIO users should use the disable driver autobinding sysfs before
creating SRIOV instance to prevent this auto binding and then bind
VFIO manually.

Or userspace can manually unbind novacore from the VF and rebind VFIO.

Jason