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 10/10] samples: rust: add Rust SR-IOV VF driver sample
Date: Wed, 30 Sep 2026 17:15:00 +0200	[thread overview]
Message-ID: <DLSQZO7U8S8U.1DDL9MVEYS7ED@kernel.org> (raw)
In-Reply-To: <a50d3eba8fca1ecf094da263a749fa012a512b7f.1790759932.git.zhiw@nvidia.com>

On Wed Sep 30, 2026 at 12:18 PM CEST, Zhi Wang wrote:
> +#[pin_data(PinnedDrop)]
> +struct PfDriverData<'bound> {
> +    // Keep the device alive until the registration stops exposing `PfApi::pdev`.

What does this mean?

> +    #[pin]
> +    _registration: pci::VfRegistration<'bound, PfApiForLt>,
> +    pdev: ARef<pci::Device>,

	pdev: &'bound pci::Device<Bound>,

> +}
> +
> +#[pin_data(PinnedDrop)]
> +struct VfDriverData {
> +    pdev: ARef<pci::Device>,

	pdev: &'bound pci::Device<Bound>,

> +}
> +
> +kernel::pci_device_table!(
> +    PF_TABLE,
> +    <SamplePfDriver as pci::Driver>::IdInfo,
> +    [(
> +        // E1000_DEV_ID_82576
> +        pci::DeviceId::from_id(pci::Vendor::INTEL, 0x10c9),
> +        ()
> +    )]
> +);
> +
> +kernel::pci_device_table!(
> +    VF_TABLE,
> +    <SampleVfDriver as pci::Driver>::IdInfo,
> +    [(
> +        // E1000_DEV_ID_82576_VF
> +        pci::DeviceId::from_id(pci::Vendor::INTEL, 0x10ca),
> +        ()
> +    )]
> +);

Since this is two drivers in the same module, can we please put everythng that
belongs to the PF driver first and then everything that belongs into the VF
driver second please? We could also make it two separate files.

> +#[vtable]
> +impl pci::Driver for SamplePfDriver {
> +    type IdInfo = ();
> +    type Data<'bound> = PfDriverData<'bound>;
> +
> +    const ID_TABLE: pci::IdTable<Self::IdInfo> = &PF_TABLE;
> +
> +    fn probe<'bound>(
> +        pdev: &'bound pci::Device<Core<'_>>,
> +        _info: Option<&'bound Self::IdInfo>,
> +    ) -> impl PinInit<Self::Data<'bound>, Error> + 'bound {
> +        pin_init::pin_init_scope(move || {
> +            dev_info!(
> +                pdev,
> +                "Probe Rust SR-IOV PF sample (PCI ID: {}, 0x{:x}).\n",
> +                pdev.vendor_id(),
> +                pdev.device_id()
> +            );
> +
> +            pdev.enable_device_mem()?;
> +            pdev.set_master();
> +
> +            Ok(try_pin_init!(PfDriverData {
> +                // SAFETY:
> +                // - probe has exclusive access to this PF before SR-IOV is enabled;
> +                // - the registration is pinned in the PF driver data and dropped before `pdev`;
> +                // - no other registration is created for this PF; and
> +                // - VFs are enabled only after probe by `sriov_enable`.
> +                _registration <- unsafe {
> +                    pci::VfRegistration::new(
> +                        pdev,
> +                        try_pin_init!(PfApi {
> +                            pdev,
> +                            requests <- new_mutex!(0),
> +                        }),
> +                    )
> +                },
> +                pdev: pdev.into(),
> +            }))
> +        })

Let's put everything within a single try_pin_init!() block please.

> +#[vtable]
> +impl pci::Driver for SampleVfDriver {
> +    type IdInfo = ();
> +    type Data<'bound> = VfDriverData;
> +
> +    const ID_TABLE: pci::IdTable<Self::IdInfo> = &VF_TABLE;
> +
> +    fn probe<'bound>(
> +        pdev: &'bound pci::Device<Core<'_>>,
> +        _info: Option<&'bound Self::IdInfo>,
> +    ) -> impl PinInit<Self::Data<'bound>, Error> + 'bound {
> +        pin_init::pin_init_scope(move || {
> +            dev_info!(
> +                pdev,
> +                "Probe Rust SR-IOV VF sample (PCI ID: {}, 0x{:x}).\n",
> +                pdev.vendor_id(),
> +                pdev.device_id()
> +            );
> +
> +            let pdev_bound: &'bound pci::Device<Bound> = pdev;
> +            let pf_api = pdev_bound.vf_registration_data::<PfApiForLt>()?;
> +
> +            pdev.enable_device_mem()?;
> +            pdev.set_master();
> +
> +            let request = pf_api.submit(pdev)?;
> +            dev_info!(pdev, "Submitted request {} through PF data.\n", request);
> +
> +            Ok(try_pin_init!(VfDriverData { pdev: pdev.into() }))
> +        })

Same here. Also no need for pdev_bound, it derefs automatically, you can just
call pdev.vf_registration_data().

> +    }
> +}
> +
> +#[pinned_drop]
> +impl PinnedDrop for PfDriverData<'_> {
> +    fn drop(self: Pin<&mut Self>) {
> +        dev_info!(self.pdev, "Remove Rust SR-IOV PF sample.\n");
> +    }
> +}
> +
> +#[pinned_drop]
> +impl PinnedDrop for VfDriverData {
> +    fn drop(self: Pin<&mut Self>) {
> +        dev_info!(self.pdev, "Remove Rust SR-IOV VF sample.\n");
> +    }
> +}

Let's drop those, we don't really need them.

Here's the two probe() functions I came up with:

    fn probe<'bound>(
        pdev: &'bound pci::Device<Core<'_>>,
        _info: Option<&'bound Self::IdInfo>,
    ) -> impl PinInit<Self::Data<'bound>, Error> + 'bound {
        try_pin_init!(PfDriverData {
            _: {
                dev_info!(
                    pdev,
                    "Probe Rust SR-IOV PF sample (PCI ID: {}, 0x{:x}).\n",
                    pdev.vendor_id(),
                    pdev.device_id()
                );
            },

            _: {
                pdev.enable_device_mem()?;
                pdev.set_master();
            },

            // SAFETY:
            // - probe has exclusive access to this PF before SR-IOV is enabled;
            // - the registration is pinned in the PF driver data and dropped before `pdev`;
            // - no other registration is created for this PF; and
            // - VFs are enabled only after probe by `sriov_enable`.
            _registration <- unsafe {
                pci::VfRegistration::new(
                    pdev,
                    try_pin_init!(PfApi {
                        pdev,
                        requests <- new_mutex!(0),
                    }),
                )
            },

            pdev,
        })
    }

    fn probe<'bound>(
        pdev: &'bound pci::Device<Core<'_>>,
        _info: Option<&'bound Self::IdInfo>,
    ) -> impl PinInit<Self::Data<'bound>, Error> + 'bound {
        try_pin_init!(VfDriverData {
            _: {
                dev_info!(
                    pdev,
                    "Probe Rust SR-IOV VF sample (PCI ID: {}, 0x{:x}).\n",
                    pdev.vendor_id(),
                    pdev.device_id()
                );
            },

            _: {
                pdev.enable_device_mem()?;
                pdev.set_master();
            },

            pdev,

            _: {
                let pf_api = pdev.vf_registration_data::<PfApiForLt>()?;

                let request = pf_api.submit(pdev)?;
                dev_info!(pdev, "Submitted request {} through PF data.\n", request);
            },
        })
    }

Note that enable_device() and set_master() have their own block as they will be
replaced with a pci::DeviceEnableGuard soon.

      reply	other threads:[~2026-09-30 15:15 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
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 [this message]

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=DLSQZO7U8S8U.1DDL9MVEYS7ED@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®