From: "Danilo Krummrich" <dakr@kernel.org>
To: "John Hubbard" <jhubbard@nvidia.com>
Cc: "Alexandre Courbot" <acourbot@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, "Surath Mitra" <smitra@nvidia.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"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 v2 1/2] rust: pci: skip probing VFs if driver doesn't support VFs
Date: Thu, 02 Oct 2025 13:49:37 +0200 [thread overview]
Message-ID: <DD7TANT8PB1W.2SVA4TOU80BFN@kernel.org> (raw)
In-Reply-To: <20251002020010.315944-2-jhubbard@nvidia.com>
On Thu Oct 2, 2025 at 4:00 AM CEST, 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.
>
> Cc: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Alistair Popple <apopple@nvidia.com>
> Cc: Joel Fernandes <joelagnelf@nvidia.com>
> Cc: Zhi Wang <zhiw@nvidia.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> drivers/pci/pci-driver.c | 3 +++
> include/linux/pci.h | 1 +
> rust/kernel/pci.rs | 4 ++++
> 3 files changed, 8 insertions(+)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 63665240ae87..588666cc7254 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -412,6 +412,9 @@ static int __pci_device_probe(struct pci_driver *drv, struct pci_dev *pci_dev)
> if (drv->probe) {
> error = -ENODEV;
>
> + if (pci_dev->is_virtfn && !drv->supports_vf)
> + return error;
> +
> id = pci_match_device(drv, pci_dev);
> if (id)
> error = pci_call_probe(drv, pci_dev, id);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 59876de13860..92510886a086 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -983,6 +983,7 @@ struct pci_driver {
> struct device_driver driver;
> struct pci_dynids dynids;
> bool driver_managed_dma;
> + bool supports_vf; /* Will bind to Virtual Functions */
I don't see any driver changes in this patch, are we sure this doesn't break any
existing drivers given that this defaults to false?
Obviously, the safe call would be to invert the logic, such that it defaults to
VFs being supported, though I clearly do prefer the opt-in.
Also, in C this always defaults to false, whereas in Rust we have the choice to
make it true by default, hence in C we'd need to invert the semantics, which is
not desirable either.
> };
>
> #define to_pci_driver(__drv) \
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index 7fcc5f6022c1..c5d036770e65 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
> @@ -47,6 +47,7 @@ unsafe fn register(
> (*pdrv.get()).probe = Some(Self::probe_callback);
> (*pdrv.get()).remove = Some(Self::remove_callback);
> (*pdrv.get()).id_table = T::ID_TABLE.as_ptr();
> + (*pdrv.get()).supports_vf = T::SUPPORTS_VF;
> }
>
> // SAFETY: `pdrv` is guaranteed to be a valid `RegType`.
> @@ -268,6 +269,9 @@ pub trait Driver: Send {
> /// The table of device ids supported by the driver.
> const ID_TABLE: IdTable<Self::IdInfo>;
>
> + /// Whether the driver supports Virtual Functions.
> + const SUPPORTS_VF: bool = false;
> +
> /// PCI driver probe.
> ///
> /// Called when a new pci device is added or discovered. Implementers should
> --
> 2.51.0
next prev parent reply other threads:[~2025-10-02 11:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 2:00 [PATCH v2 0/2] rust: pci: don't probe() VFs in nova-core John Hubbard
2025-10-02 2:00 ` [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't support VFs John Hubbard
2025-10-02 11:49 ` Danilo Krummrich [this message]
2025-10-02 12:11 ` Jason Gunthorpe
2025-10-02 12:18 ` Danilo Krummrich
2025-10-02 12:39 ` Jason Gunthorpe
2025-10-02 13:03 ` Danilo Krummrich
2025-10-02 13:56 ` Jason Gunthorpe
2025-10-02 15:11 ` Danilo Krummrich
2025-10-02 15:23 ` Jason Gunthorpe
2025-10-02 16:05 ` Danilo Krummrich
2025-10-02 17:05 ` Jason Gunthorpe
2025-10-02 17:37 ` Danilo Krummrich
2025-10-02 17:40 ` Danilo Krummrich
2025-10-02 17:49 ` John Hubbard
2025-10-02 18:05 ` Jason Gunthorpe
2025-10-02 18:09 ` John Hubbard
2025-10-02 18:32 ` Jason Gunthorpe
2025-10-02 18:17 ` Danilo Krummrich
2025-10-02 18:31 ` Jason Gunthorpe
2025-10-02 18:42 ` Danilo Krummrich
2025-10-02 18:56 ` Jason Gunthorpe
2025-10-02 19:36 ` Danilo Krummrich
2025-10-02 21:04 ` Jason Gunthorpe
2025-10-02 21:14 ` Danilo Krummrich
2025-10-02 21:32 ` Danilo Krummrich
2025-10-02 23:40 ` Jason Gunthorpe
2025-10-03 0:57 ` Danilo Krummrich
2025-10-03 11:52 ` Jason Gunthorpe
2025-10-02 17:56 ` Jason Gunthorpe
2025-10-02 18:55 ` Danilo Krummrich
2025-10-02 2:00 ` [PATCH v2 2/2] gpu: nova-core: declare that VFs are not (yet) supported John Hubbard
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=DD7TANT8PB1W.2SVA4TOU80BFN@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=alex.williamson@redhat.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=jgg@nvidia.com \
--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).