From: Zhi Wang <zhiw@nvidia.com>
To: <rust-for-linux@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: <dakr@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>, <joelagnelf@nvidia.com>,
<jhubbard@nvidia.com>, Zhi Wang <zhiw@nvidia.com>,
<daniel.almeida@collabora.com>, <tamird@kernel.org>,
<work@onurozkan.dev>
Subject: Re: [PATCH v7 0/1] Rust PCI capability infrastructure and SR-IOV support
Date: Thu, 13 Aug 2026 09:54:59 +0300 [thread overview]
Message-ID: <20260813095452.2218a668@inno-dell> (raw)
In-Reply-To: <20260804161612.776752-1-zhiw@nvidia.com>
On Tue, 4 Aug 2026 19:16:10 +0300
Zhi Wang <zhiw@nvidia.com> wrote:
Gentle ping. :)
> This is a follow-up to v6 [10].
>
> This patch has been used in the Boot GSP with vGPU enabled series [6].
>
> The patch defines an ExtCapability trait that associates an extended
> capability ID with its register layout. The generic
> ConfigSpace::find_ext_capability() finder locates the capability,
> bounds it at the next capability or the end of extended configuration
> space, and projects the ConfigSpace view to the requested layout. It
> returns None when the capability is absent and propagates errors
> encountered while constructing the view. This lets the existing I/O
> projection and access macros operate on capability registers.
>
> ExtSriovRegs provides the SR-IOV register layout.
> ExtSriovCapability::vf_bars() validates the six raw VF BAR slots and
> returns an iterator over logical BARs. The iterator handles the
> different slot widths of 32-bit and 64-bit BARs internally and yields
> decoded ExtSriovVfBar values containing the address and width. A
> typed bitfield decodes each low DWORD while the register layout
> remains an array of raw u32 values. ExtSriovCapability remains as a
> convenience alias.
>
> Changes since v6:
> - Changed ConfigSpace::find_ext_capability() to return
> Result<Option<...>>, using None rather than ENODEV when the
> capability is absent. (Gary)
> - Made calculate_ext_cap_size() propagate errors instead of treating a
> failed read as the end of capability. (Alex)
> - Replaced indexed VF BAR access with an iterator so callers cannot
> select the high DWORD of a 64-bit BAR. (Gary, Alex)
> - Validated all six VF BAR slots before iteration, made normal
> iterator exhaustion return None, and logged invalid BAR encodings
> before returning EINVAL. (Gary)
> - Decoded VF BAR low DWORDs through a typed bitfield while retaining
> u32 in ExtSriovRegs for entries that may be 64-bit BAR high DWORDs.
> (Alex)
> - Made ExtSriovVfBar fields public and documented, removed their
> trivial getters, used the ExtSriovCapability alias for its impl
> block, and applied the suggested local cleanups. (Alex)
> - Updated the doctest for the optional finder result and VF BAR
> iterator. (Zhi)
> - Added #[inline] to the ExtCapId::as_raw() abstraction method.
> (Sashiko)
> - Rebased onto the latest drm-rust-next. (Zhi)
>
> Changes since v5:
> - Removed the unused ConfigSpace<Region<0>> offset() and size()
> inherent methods; ConfigSpace already provides size through the Io
> trait. (Sashiko, Zhi)
> - Removed the doctest write to the SR-IOV NumVFs register, avoiding an
> example that bypasses PCI core SR-IOV state management. (Sashiko)
> - Corrected Function Dependency Link to an 8-bit field followed by its
> reserved byte, matching the PCIe SR-IOV register layout. (Sashiko)
>
> Changes since v4:
> - Replaced the separate is_vf_bar_64bit() and read_vf_bar64() helpers
> with read_vf_bar(), returning a decoded ExtSriovVfBar. (Zhi)
> - Moved memory BAR attribute stripping into the PCI abstraction and
> used named PCI attribute definitions rather than an open-coded mask.
> (Zhi)
> - Exposed the next logical BAR slot so callers can walk mixed 32-bit
> and 64-bit VF BAR layouts without duplicating slot arithmetic. (Zhi)
> - Updated the doctest and PCI exports for the decoded BAR API. (Zhi)
>
> Changes since v3:
> - Replaced the custom ExtCapability<T> I/O wrapper with the existing
> ConfigSpace view infrastructure. (Alex)
> - Reused ExtCapability as a trait carrying the capability ID, and made
> ConfigSpace::find_ext_capability() generic over register layouts.
> (Alex)
> - Removed public cast_sized() and unused find_next_ext_capability().
> (Alex)
> - Kept capability construction in the generic finder and documented
> calculate_ext_cap_size(). (Alex)
> - Used PCI_SRIOV_NUM_BARS rather than a literal VF BAR count.
> (Alex, Zhi)
> - Added is_vf_bar_64bit() and made read_vf_bar64() reject BARs that
> are not 64-bit memory BARs. (Alex, Zhi)
> - Kept indexed VF BAR helpers because the Nova user accesses fixed BAR
> slots rather than iterating over them. (Alex)
> - Adapted the implementation and doctest to the current ConfigSpace
> I/O APIs. (Zhi)
>
> Changes since RFC v2:
> - Hardened calculate_ext_cap_size() against corrupt capability lists.
> (Zhi)
> - Added // INVARIANT: comments at all ExtCapability construction sites
> (make_ext_capability and cast_sized). (Zhi)
> - Added #[inline] to small forwarding methods (find, read_vf_bar64).
> (Zhi)
>
> Changes since RFC:
> - Rebased on io_projection branch, using Gary's Io/IoCapable traits.
> (Gary)
> - ExtCapability implements Io and delegates IoCapable to ConfigSpace
> instead of duplicating config read/write logic. (Gary)
> - Dropped the fallible I/O patch (now upstream in this tree). (Zhi)
> - Added Rust helper for PCI_EXT_CAP_NEXT() macro. (Zhi)
> - Replaced raw `as` casts with From conversions where possible. (Zhi)
> - Renamed SriovRegs/SriovCapability to
> ExtSriovRegs/ExtSriovCapability. (Zhi)
>
> [1]
> https://lore.kernel.org/rust-for-linux/20260409185254.3869808-1-zhiw@nvidia.com/
> [2]
> https://lore.kernel.org/rust-for-linux/DHRTUAF52GNI.1J98TSAG1LS6Q@nvidia.com/
> [3]
> https://lore.kernel.org/rust-for-linux/DI2SL4G5INLY.2W1IFTR081ID3@nvidia.com/
> [4]
> https://lore.kernel.org/rust-for-linux/20260225180449.1813833-1-zhiw@nvidia.com/
> [5]
> https://lore.kernel.org/rust-for-linux/20260323153807.1360705-1-gary@kernel.org/
> [6]
> https://lore.kernel.org/rust-for-linux/20260313165336.935771-1-zhiw@nvidia.com/
> [7]
> https://lore.kernel.org/rust-for-linux/20260714165827.2937960-1-zhiw@nvidia.com/
> [8]
> https://lore.kernel.org/rust-for-linux/20260730180349.771719-1-zhiw@nvidia.com/
> [9]
> https://sashiko.dev/#/patchset/20260730180349.771719-2-zhiw@nvidia.com?part=1
> [10]
> https://lore.kernel.org/rust-for-linux/20260730182954.783568-1-zhiw@nvidia.com/
> [11]
> https://lore.kernel.org/rust-for-linux/DKC4MR1ZBQMP.3L7X2C96OJLFU@garyguo.net/
> [12]
> https://lore.kernel.org/rust-for-linux/DKCOUE9DRG5R.2VAVA78UTVKST@nvidia.com/
> [13]
> https://lore.kernel.org/rust-for-linux/DKCRGMZJXO6X.1SWGREC78DH0W@garyguo.net/
> [14]
> https://lore.kernel.org/linux-pci/20260730183913.B00061F000E9@smtp.kernel.org/
>
> Zhi Wang (1):
> rust: pci: add extended capability and SR-IOV support
>
> rust/helpers/pci.c | 5 +
> rust/kernel/pci.rs | 8 ++
> rust/kernel/pci/cap.rs | 317
> +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 330
> insertions(+) create mode 100644 rust/kernel/pci/cap.rs
>
>
> base-commit: 44e7e7f7cffb10a93bb88e7cb59b7b8b3e2deb1c
prev parent reply other threads:[~2026-08-13 6:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 16:16 [PATCH v7 0/1] Rust PCI capability infrastructure and SR-IOV support Zhi Wang
2026-08-04 16:16 ` [PATCH v7 1/1] rust: pci: add extended capability " Zhi Wang
2026-08-13 6:54 ` Zhi Wang [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=20260813095452.2218a668@inno-dell \
--to=zhiw@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--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=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@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=rust-for-linux@vger.kernel.org \
--cc=smitra@nvidia.com \
--cc=tamird@kernel.org \
--cc=targupta@nvidia.com \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
/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