Rust for Linux List
 help / color / mirror / Atom feed
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


      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