mirror of https://lore.kernel.org/lkml/
 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: 21+ 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-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:18 ` [PATCH v3 07/10] rust: pci: add typed SR-IOV PF registration data Zhi Wang
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 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 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
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 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®