All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhi Wang <zhiw@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>
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: Sun, 4 Oct 2026 08:07:11 +0200	[thread overview]
Message-ID: <20261004080711.011f0ce6@inno-x280> (raw)
In-Reply-To: <DLSPDU29TZ0B.1O7PTVMMYQSHS@kernel.org>

On Wed, 30 Sep 2026 15:59:27 +0200
"Danilo Krummrich" <dakr@kernel.org> wrote:

> 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.
> 

I see. 

> You could have something like Mutex<Option<_>> of course, but that
> would be intentional then.
> 

Got it. Will proceed in the next re-spin.

> > != 0 {
> > +                // 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?
> 

Nice idea. Thanks for the suggestion.

> > +
> > +                // 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 =

<snip>

> > +    ///
> > +    /// 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.

Got it. I will add a helper for the PF driver to access 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
> 


  reply	other threads:[~2026-10-04  6:07 UTC|newest]

Thread overview: 31+ 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:34   ` sashiko-bot
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:36   ` sashiko-bot
2026-09-30 10:18 ` [PATCH v3 03/10] rust: pci: add is_virtfn(), to check for VFs Zhi Wang
2026-09-30 10:34   ` sashiko-bot
2026-09-30 10:18 ` [PATCH v3 04/10] rust: pci: add is_physfn(), to check for PFs Zhi Wang
2026-09-30 10:30   ` sashiko-bot
2026-09-30 10:18 ` [PATCH v3 05/10] rust: pci: add num_vf(), to return number of VFs Zhi Wang
2026-09-30 10:32   ` sashiko-bot
2026-09-30 11:13   ` Danilo Krummrich
2026-10-03 17:12     ` Zhi Wang
2026-09-30 10:18 ` [PATCH v3 06/10] rust: pci: drop driver data before remove returns Zhi Wang
2026-09-30 10:35   ` sashiko-bot
2026-09-30 10:18 ` [PATCH v3 07/10] rust: pci: add typed SR-IOV PF registration data Zhi Wang
2026-09-30 10:36   ` sashiko-bot
2026-09-30 13:59   ` Danilo Krummrich
2026-10-04  6:07     ` Zhi Wang [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 10:37   ` sashiko-bot
2026-09-30 14:25   ` Danilo Krummrich
2026-10-04  6:16     ` Zhi Wang
2026-09-30 10:18 ` [PATCH v3 09/10] rust: pci: add SR-IOV enable and disable callbacks Zhi Wang
2026-09-30 10:37   ` sashiko-bot
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 10:46   ` sashiko-bot
2026-09-30 15:15   ` Danilo Krummrich
2026-10-04  6:21     ` Zhi Wang

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=20261004080711.011f0ce6@inno-x280 \
    --to=zhiw@nvidia.com \
    --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=dakr@kernel.org \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.