From: "Danilo Krummrich" <dakr@kernel.org>
To: "John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>
Cc: "Alexandre Courbot" <acourbot@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>, "Zhi Wang" <zhiw@nvidia.com>,
"Surath Mitra" <smitra@nvidia.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
nouveau@lists.freedesktop.org, linux-pci@vger.kernel.org,
rust-for-linux@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core
Date: Wed, 01 Oct 2025 12:32:02 +0200 [thread overview]
Message-ID: <DD6X0PXA0VAO.101O3FEAHJUH9@kernel.org> (raw)
In-Reply-To: <e77bbcda-35a3-4ec6-ac24-316ab34a201a@nvidia.com>
On Wed Oct 1, 2025 at 3:22 AM CEST, John Hubbard wrote:
> On 9/30/25 5:29 PM, Alistair Popple wrote:
>> On 2025-10-01 at 08:07 +1000, John Hubbard <jhubbard@nvidia.com> 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.
>>>
>>> Add a method to check if a PCI device is a Virtual Function (VF). This
>>> allows Rust drivers to determine whether a device is a VF created
>>> through SR-IOV. This is required in order to implement VFIO, because
>>> drivers such as NovaCore must only bind to Physical Functions (PFs) or
>>> regular PCI devices. The VFs must be left unclaimed, so that a VFIO
>>> kernel module can claim them.
>>
>> Curiously based on a quick glance I didn't see any other drivers doing this
>> which makes me wonder why we're different here. But it seems likely their
>> virtual functions are supported by the same driver rather than requiring a
>> different VF specific driver (or I glanced too quickly!).
>
> I haven't checked into that, but it sounds reasonable.
There are multiple cases:
Some devices have different PCI device IDs for their physical and virtual
functions and different drivers handling then. One example for that is Intel
IXGBE.
But there are also some drivers, which do a similar check and just stop probing
if they detect a virtual function.
So, this patch series does not do anything uncommon.
>> I'm guessing the proposal is to fail the probe() function in nova-core for
>> the VFs - I'm not sure but does the driver core continue to try probing other
>> drivers if one fails probe()? It seems like this would be something best
>> filtered on in the device id table, although I understand that's not possible
>> today.
Yes, the driver core keeps going until it finds a driver that succeeds probing
or no driver is left to probe. (This behavior is also the reason for the name
probe() in the first place.)
However, nowadays we ideally know whether a driver fits a device before probe()
is called, but there are still exceptions; with PCI virtual functions we've just
hit one of those.
Theoretically, we could also indicate whether a driver handles virtual functions
through a boolean in struct pci_driver, which would be a bit more elegant.
If you want I can also pick this up with my SR-IOV RFC which will probably touch
the driver structure as well; I plan to send something in a few days.
next prev parent reply other threads:[~2025-10-01 10:32 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 22:07 [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core John Hubbard
2025-09-30 22:07 ` [PATCH 1/2] rust: pci: add is_virtfn(), to check for VFs John Hubbard
2025-10-01 0:30 ` Alistair Popple
2025-09-30 22:07 ` [PATCH 2/2] gpu: nova-core: reject binding to SR-IOV Virtual Functions John Hubbard
2025-10-01 0:33 ` Alistair Popple
2025-10-01 1:26 ` John Hubbard
2025-10-01 0:26 ` [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core Alexandre Courbot
2025-10-01 1:26 ` John Hubbard
2025-10-01 1:39 ` Alexandre Courbot
2025-10-01 1:45 ` John Hubbard
2025-10-01 8:09 ` Zhi Wang
2025-10-01 14:48 ` Jason Gunthorpe
2025-10-01 21:13 ` Zhi Wang
2025-10-02 1:43 ` Alexandre Courbot
2025-10-02 1:50 ` John Hubbard
2025-10-02 11:58 ` Jason Gunthorpe
2025-10-02 12:59 ` Zhi Wang
2025-10-02 13:42 ` Jason Gunthorpe
2025-10-02 14:29 ` Zhi Wang
2025-10-02 14:31 ` Jason Gunthorpe
2025-10-07 6:51 ` Zhi Wang
2025-10-07 10:14 ` Danilo Krummrich
2025-10-07 11:00 ` Zhi Wang
2025-10-07 11:26 ` Jason Gunthorpe
2025-10-01 14:46 ` Jason Gunthorpe
2025-10-01 18:16 ` Alex Williamson
2025-10-01 18:30 ` Jason Gunthorpe
2025-10-01 22:35 ` John Hubbard
2025-10-02 7:41 ` Zhi Wang
2025-10-01 0:29 ` Alistair Popple
2025-10-01 1:22 ` John Hubbard
2025-10-01 10:32 ` Danilo Krummrich [this message]
2025-10-01 13:52 ` Zhi Wang
2025-10-01 22:38 ` John Hubbard
2025-10-01 22:52 ` Danilo Krummrich
2025-10-01 23:00 ` John Hubbard
2025-10-01 23:47 ` Joel Fernandes
2025-10-01 23:51 ` John Hubbard
2025-10-01 23:55 ` Danilo Krummrich
2025-10-02 0:48 ` Joel Fernandes
2025-10-02 0:54 ` John Hubbard
2025-10-02 12:05 ` Jason Gunthorpe
2025-10-02 12:01 ` Jason Gunthorpe
2025-10-02 12:08 ` Danilo Krummrich
2025-10-02 12:32 ` Jason Gunthorpe
2025-10-02 12:41 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DD6X0PXA0VAO.101O3FEAHJUH9@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=smitra@nvidia.com \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).