[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4669209d-c53b-4cc5-ab2f-0f09aa5dfc50@de.bosch.com>
Date: Fri, 6 Feb 2026 08:45:42 +0100
From: Dirk Behme <dirk.behme@...bosch.com>
To: Peter Colberg <pcolberg@...hat.com>, Danilo Krummrich <dakr@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>, Krzysztof Wilczyński
<kwilczynski@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor
<alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo
<gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, "Andreas
Hindborg" <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, "Trevor
Gross" <tmgross@...ch.edu>, Abdiel Janulgue <abdiel.janulgue@...il.com>,
Daniel Almeida <daniel.almeida@...labora.com>, Robin Murphy
<robin.murphy@....com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Dave Ertman" <david.m.ertman@...el.com>, Ira Weiny <ira.weiny@...el.com>,
"Leon Romanovsky" <leon@...nel.org>, David Airlie <airlied@...il.com>, Simona
Vetter <simona@...ll.ch>, Jonathan Corbet <corbet@....net>, Xu Yilun
<yilun.xu@...el.com>, Tom Rix <trix@...hat.com>, Moritz Fischer
<mdf@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Zhi Wang
<zhiw@...dia.com>, Zijing Zhang <zijing.zhang@...rs>
CC: <linux-pci@...r.kernel.org>, <rust-for-linux@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Alexandre Courbot <acourbot@...dia.com>,
Alistair Popple <apopple@...dia.com>, Joel Fernandes <joelagnelf@...dia.com>,
John Hubbard <jhubbard@...dia.com>, Zhi Wang <zhiw@...dia.com>,
<nouveau@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>,
<linux-doc@...r.kernel.org>, <linux-fpga@...r.kernel.org>,
<driver-core@...ts.linux.dev>, Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: [PATCH v2 00/10] rust: pci: add abstractions for SR-IOV
capability
On 05.02.2026 21:59, Peter Colberg wrote:
> Add Rust abstractions for the Single Root I/O Virtualization (SR-IOV)
> capability of a PCI device. Provide a minimal set of wrappers for the
> SR-IOV C API to enable and disable SR-IOV for a device, and query if
> a PCI device is a Physical Function (PF) or Virtual Function (VF).
>
> Using the #[vtable] attribute, extend the pci::Driver trait with an
> optional bus callback sriov_configure() that is invoked when a
> user-space application writes the number of VFs to the sysfs file
> `sriov_numvfs` to enable SR-IOV, or zero to disable SR-IOV [1].
>
> Add a method physfn() to return the Physical Function (PF) device for a
> Virtual Function (VF) device in the bound device context. Unlike for a
> PCI driver written in C, guarantee that when a VF device is bound to a
> driver, the underlying PF device is bound to a driver, too.
>
> When a device with enabled VFs is unbound from a driver, invoke the
> sriov_configure() callback to disable SR-IOV before the remove()
> callback. To ensure the guarantee is upheld, call disable_sriov()
> to remove all VF devices if the driver has not done so already.
>
> For PF drivers written in C, disabling SR-IOV on remove() may be opted
> into by setting the flag managed_sriov in the pci_driver structure. For
> PF drivers written in Rust, disabling SR-IOV on unbind() is mandatory.
>
> This series is based on Danilo Krummrich's series "Device::drvdata() and
> driver/driver interaction (auxiliary)" applied to driver-core-next,
> which similarly guarantees that when an auxiliary bus device is bound to
> a driver, the underlying parent device is bound to a driver, too [2, 3].
>
> Add an SR-IOV driver sample that exercises the SR-IOV capability using
> QEMU's 82576 (igb) emulation and was used to test the abstractions [4].
>
> [1] https://docs.kernel.org/PCI/pci-iov-howto.html
> [2] https://lore.kernel.org/rust-for-linux/20251020223516.241050-1-dakr@kernel.org/
> [3] https://lore.kernel.org/rust-for-linux/20260107103511.570525-7-dakr@kernel.org/
> [4] https://www.qemu.org/docs/master/system/devices/igb.html
>
> Signed-off-by: Peter Colberg <pcolberg@...hat.com>
> ---
> Changes in v2:
> - Move logic to disable SR-IOV on remove() from Rust to C.
> - Add driver flag managed_sriov to opt into disabling SR-IOV on remove().
> - Demonstrate flag managed_sriov for dfl-pci driver.
> - Uphold safety guarantee for physfn() when PF driver is written in C.
> - Let physfn() return error if driver flag managed_sriov is unset.
> - Use "kernel vertical" style on imports.
> - Use to_result() to handle error in enable_sriov().
> - Note Bound device context in SAFETY comments for {enable,disable}_sriov().
> - Demonstrate how to reach driver data of PF device from VF device.
> - Add missing #[vtable] attribute in PCI driver trait example.
> - Add missing #[vtable] attribute in nova-core driver.
> - Define struct MyDriver such that physfn() example compiles.
> - Replace VF -> PF in doc comment of is_physfn().
> - Add #[inline] to is_physfn() and is_virtfn().
> - Link to v1: https://lore.kernel.org/r/20251119-rust-pci-sriov-v1-0-883a94599a97@redhat.com
>
> ---
> John Hubbard (1):
> rust: pci: add is_virtfn(), to check for VFs
>
> Peter Colberg (9):
> PCI: add driver flag to opt into disabling SR-IOV on remove()
> fpga: dfl-pci: set driver flag to disable SR-IOV on remove()
> rust: pci: add {enable,disable}_sriov(), to control SR-IOV capability
> rust: pci: add vtable attribute to pci::Driver trait
> rust: pci: add bus callback sriov_configure(), to control SR-IOV from sysfs
> rust: pci: add is_physfn(), to check for PFs
> rust: pci: add num_vf(), to return number of VFs
> rust: pci: add physfn(), to return PF device for VF device
> samples: rust: add SR-IOV driver sample
Would it make sense to somehow align / coordinate / stack this with the
work from Zhi Wang (and Zijing Zhang)
https://lore.kernel.org/rust-for-linux/20260126215957.541180-3-zhiw@nvidia.com/
? Or is this completely orthogonal?
Best regards
Dirk
Powered by blists - more mailing lists