mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®