All of lore.kernel.org
 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: 6+ 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-04 16:33   ` sashiko-bot
2026-08-13 13:04   ` Gary Guo
2026-08-13 13:56   ` Danilo Krummrich
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.