From: "Danilo Krummrich" <dakr@kernel.org>
To: "Zhi Wang" <zhiw@nvidia.com>
Cc: <rust-for-linux@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <aliceryhl@google.com>,
<bhelgaas@google.com>, <kwilczynski@kernel.org>,
<ojeda@kernel.org>, <boqun@kernel.org>, <gary@garyguo.net>,
<bjorn3_gh@protonmail.com>, <lossin@kernel.org>,
<a.hindborg@kernel.org>, <tmgross@umich.edu>,
<markus.probst@posteo.de>, <cjia@nvidia.com>, <smitra@nvidia.com>,
<ankita@nvidia.com>, <aniketa@nvidia.com>, <kwankhede@nvidia.com>,
<targupta@nvidia.com>, <kjaju@nvidia.com>, <alkumar@nvidia.com>,
<acourbot@nvidia.com>, <jhubbard@nvidia.com>,
<zhiwang@kernel.org>, <jgg@nvidia.com>, <alex@shazbot.org>,
"Peter Colberg" <peter@colberg.org>
Subject: Re: [PATCH v3 07/10] rust: pci: add typed SR-IOV PF registration data
Date: Wed, 30 Sep 2026 15:59:27 +0200 [thread overview]
Message-ID: <DLSPDU29TZ0B.1O7PTVMMYQSHS@kernel.org> (raw)
In-Reply-To: <9fa15232fb869a562973454d9d21a5287b3da080.1790759932.git.zhiw@nvidia.com>
On Wed Sep 30, 2026 at 12:18 PM CEST, Zhi Wang wrote:
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index 1599b3a613d7..8782e9b06e64 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
> @@ -51,6 +51,8 @@
> Extended,
> Normal, //
> };
> +#[cfg(CONFIG_PCI_IOV)]
> +pub use self::iov::VfRegistration;
> pub use self::irq::{
> IrqType,
> IrqTypes,
> @@ -331,6 +333,9 @@ fn probe<'bound>(
> /// operations to gracefully tear down the device.
> ///
> /// Otherwise, release operations for driver resources should be performed in `Drop`.
> + ///
> + /// For a PF with enabled VFs, `VfRegistration` disables SR-IOV when it is dropped. This
> + /// callback must leave resources accessed by VF drivers available until then.
I don't think we need this comment, neither this callback (which I plan to
remove anyway) nor T::Data::drop() can remove resources that can still be
accessed by VF drivers in the first place.
You could have something like Mutex<Option<_>> of course, but that would be
intentional then.
> +impl<'a, F: ForLt + 'static> VfRegistrationData<'a, F> {
> + /// Pin-initializer for the registration data.
> + fn new(data: impl PinInit<F::Of<'a>, Error>) -> impl PinInit<Self, Error> {
I think we can accept any error type E?
> + try_pin_init!(Self {
> + type_id: TypeId::of::<F>(),
> + data <- data,
> + })
> + }
> +}
<snip>
> +impl<'a, F: ForLt + 'static> VfRegistration<'a, F>
> +where
> + for<'b> F::Of<'b>: Send + Sync,
> +{
> + /// Create a new VF registration.
> + ///
> + /// Returns a pin-initializer so the registration can be embedded directly
> + /// in the PF driver's bus device private data.
> + ///
> + /// # Safety
> + ///
> + /// The returned registration must be embedded in the driver's bus device private data.
I think this is the only requirement we need.
> + /// The initializer must run as part of the PF driver's probe.
> + /// The driver's `unbind` callback and the enclosing data's destructor must keep resources
> + /// accessed by VF drivers available until this registration has disabled SR-IOV.
This is not a safety requirement; it would require unsafe code to do this.
> + pub unsafe fn new(
> + pdev: &'a Device<device::Core<'_>>,
> + data: impl PinInit<F::Of<'a>, Error> + 'a,
> + ) -> impl PinInit<Self, Error> + 'a {
> + let pdev: &'a Device<device::Bound> = pdev;
> + try_pin_init!(Self {
> + _: {
> + if pdev.is_virtfn() {
> + return Err(ENODEV);
> + }
> + },
> + pdev,
> + inner <- VfRegistrationData::new(data),
> + _pin: PhantomPinned,
> + _: {
> + // Check after initialization in case it registered another object for this PF.
> + // SAFETY: The caller runs this initializer during PF probing, before VF
> + // configuration callbacks can run.
> + if unsafe { bindings::pci_num_vf(pdev.as_raw()) } != 0 {
Don't we have a safe pci::Device::num_vf() method already?
> + return Err(EBUSY);
> + }
> +
> + // SAFETY: This initializer runs during PF probing, and no VFs are enabled.
> + if !unsafe { (*pdev.as_raw()).vf_registration_data_rust }.is_null() {
> + return Err(EBUSY);
> + }
Those two checks can go into the first _: block, no?
> +
> + // SAFETY: The data is initialized and pinned, the slot is unoccupied, and
> + // no VF can access it yet. No fallible work follows publication.
> + unsafe {
> + (*pdev.as_raw()).vf_registration_data_rust =
> + core::ptr::from_ref(inner.as_ref().get_ref()).cast_mut().cast();
> + }
> + },
> + })
> + }
> +}
> +
> +#[pinned_drop]
> +impl<F: ForLt + 'static> PinnedDrop for VfRegistration<'_, F> {
> + fn drop(self: Pin<&mut Self>) {
> + // SAFETY: `pci_disable_sriov()` is safe to call on any `pci_dev`; it
> + // is a no-op if the device has no VFs enabled. When VFs are enabled,
> + // this blocks until all VF `remove()` callbacks complete.
> + unsafe { bindings::pci_disable_sriov(self.pdev.as_raw()) };
> +
> + // SAFETY: The device is valid and all VF remove callbacks have completed, so no VF
> + // can access the registration pointer. The data remains alive until this returns.
> + unsafe { (*self.pdev.as_raw()).vf_registration_data_rust = core::ptr::null_mut() };
> + }
> +}
> +
> +// SAFETY: The inner data is `Send` (enforced by the bound), and `&Device` is `Send + Sync`.
> +unsafe impl<F: ForLt> Send for VfRegistration<'_, F> where for<'a> F::Of<'a>: Send {}
> +
> +// SAFETY: The inner data is `Send + Sync`. `VfRegistration` doesn't expose mutable access;
> +// VF drivers only read the data through an immutable pinned reference.
> +unsafe impl<F: ForLt> Sync for VfRegistration<'_, F> where for<'a> F::Of<'a>: Send + Sync {}
> +
> +impl Device<device::Bound> {
> + /// Internal helper: reads the `vf_registration_data_rust` pointer from the
> + /// PF, checks the `TypeId`, and returns a pinned reference.
> + ///
> + /// # Safety
> + ///
> + /// The data lifetime must be hidden behind a higher-ranked closure independently of the
> + /// reference lifetime, or `F` must be covariant in its encoded lifetime.
> + unsafe fn vf_registration_data_pinned<F: ForLt + 'static>(&self) -> Result<Pin<&F::Of<'_>>> {
> + if !self.is_virtfn() {
> + return Err(ENODEV);
> + }
We don't want to exclude PF drivers to access this. Have a look at
drivers/gpu/nova-core/api.rs, it makes sense for the PF driver to provide a
helper API around this.
> + // SAFETY: This bound VF uses the `physfn` union field. PCI retains its PF until
> + // VF removal completes, and the PF keeps the registration installed until then.
> + let ptr = unsafe {
> + let pf = (*self.as_raw()).__bindgen_anon_1.physfn;
> + (*pf).vf_registration_data_rust
> + };
> +
> + if ptr.is_null() {
> + return Err(ENOENT);
Maybe ENODEV?
> + }
> +
> + // SAFETY: The registration keeps its data installed until VF removal completes,
> + // including when probe initialization rolls back.
> + // `ptr` points to a `VfRegistrationData` whose first field is a `TypeId`.
> + let type_id = unsafe { ptr.cast::<TypeId>().read() };
> + if type_id != TypeId::of::<F>() {
> + return Err(EINVAL);
> + }
> +
> + // SAFETY: TypeId check confirms the stored type matches `F`. The data
> + // is pinned inside the PF's driver data struct. Lifetime shortening
> + // from the PF's binding scope to `'_` is layout-compatible.
> + let data_ptr = unsafe {
> + let vfrd = ptr.cast::<VfRegistrationData<'_, F>>();
> + &raw const (*vfrd).data
> + };
> +
> + // SAFETY: `data` is structurally pinned inside `VfRegistrationData`.
> + Ok(unsafe { Pin::new_unchecked(&*data_ptr) })
> + }
> +
> + /// Access the VF registration data through a closure with an HRTB lifetime.
> + ///
> + /// `F` is the [`ForLt`](trait@ForLt) encoding of the data type. Returns
> + /// [`ENODEV`] if this is not a VF, [`ENOENT`] if no data was registered,
> + /// or [`EINVAL`] if `F` does not match the type registered by the PF.
> + ///
> + /// The reference is borrowed from this VF, while the registration data's lifetime remains
> + /// abstract so the closure cannot store shorter-lived references in invariant data.
> + pub fn vf_registration_data_with<'this, F: ForLt + 'static, R>(
> + &'this self,
> + f: impl for<'a> FnOnce(Pin<&'this F::Of<'a>>) -> R,
> + ) -> Result<R> {
> + // SAFETY: The closure is higher-ranked over the data lifetime, independently of `'this`.
> + // It cannot insert shorter-lived references, and the outer borrow cannot outlive this VF.
> + let pinned = unsafe { self.vf_registration_data_pinned::<F>()? };
> + Ok(f(pinned))
> + }
> +
> + /// Returns a pinned reference to the VF registration data.
> + ///
> + /// Available only when `F` implements [`CovariantForLt`](trait@crate::types::CovariantForLt),
> + /// guaranteeing that shortening the PF data lifetime is sound.
> + ///
> + /// For non-covariant types, use [`Self::vf_registration_data_with()`].
> + ///
> + /// It returns the same errors as [`Self::vf_registration_data_with()`].
> + pub fn vf_registration_data<F: CovariantForLt + 'static>(&self) -> Result<Pin<&F::Of<'_>>> {
> + // SAFETY: `CovariantForLt` permits shortening the encoded lifetime to this borrow.
> + unsafe { self.vf_registration_data_pinned::<F>() }
> + }
> +}
> --
> 2.53.0
next prev parent reply other threads:[~2026-09-30 13:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 10:18 [PATCH v3 00/10] Add Rust PCI SR-IOV support Zhi Wang
2026-09-30 10:18 ` [PATCH v3 01/10] rust: pci: add internal SR-IOV enable and disable helpers Zhi Wang
2026-09-30 10:58 ` Danilo Krummrich
2026-09-30 10:18 ` [PATCH v3 02/10] rust: pci: add vtable attribute to pci::Driver trait Zhi Wang
2026-09-30 10:18 ` [PATCH v3 03/10] rust: pci: add is_virtfn(), to check for VFs Zhi Wang
2026-09-30 10:18 ` [PATCH v3 04/10] rust: pci: add is_physfn(), to check for PFs Zhi Wang
2026-09-30 10:18 ` [PATCH v3 05/10] rust: pci: add num_vf(), to return number of VFs Zhi Wang
2026-09-30 11:13 ` Danilo Krummrich
2026-09-30 10:18 ` [PATCH v3 06/10] rust: pci: drop driver data before remove returns Zhi Wang
2026-09-30 10:18 ` [PATCH v3 07/10] rust: pci: add typed SR-IOV PF registration data Zhi Wang
2026-09-30 13:59 ` Danilo Krummrich [this message]
2026-09-30 10:18 ` [PATCH v3 08/10] rust: pci: add SR-IOV enable and disable tokens Zhi Wang
2026-09-30 14:25 ` Danilo Krummrich
2026-09-30 10:18 ` [PATCH v3 09/10] rust: pci: add SR-IOV enable and disable callbacks Zhi Wang
2026-09-30 14:46 ` Danilo Krummrich
2026-09-30 10:18 ` [PATCH v3 10/10] samples: rust: add Rust SR-IOV VF driver sample Zhi Wang
2026-09-30 15:15 ` 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=DLSPDU29TZ0B.1O7PTVMMYQSHS@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=alex@shazbot.org \
--cc=aliceryhl@google.com \
--cc=alkumar@nvidia.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=cjia@nvidia.com \
--cc=gary@garyguo.net \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kjaju@nvidia.com \
--cc=kwankhede@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=markus.probst@posteo.de \
--cc=ojeda@kernel.org \
--cc=peter@colberg.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=smitra@nvidia.com \
--cc=targupta@nvidia.com \
--cc=tmgross@umich.edu \
--cc=zhiw@nvidia.com \
--cc=zhiwang@kernel.org \
/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
all inboxes | Powered by JetHome®