Rust for Linux List
 help / color / mirror / Atom feed
* [RFC 0/2] Rust PCI capability infrastructure and SR-IOV support
@ 2026-01-26 21:59 Zhi Wang
  2026-01-26 21:59 ` [RFC 1/2] pci: Add fallible I/O methods to ConfigSpace Zhi Wang
  2026-01-26 21:59 ` [RFC 2/2] pci: Add PCI capability infrastructure and SR-IOV capability support Zhi Wang
  0 siblings, 2 replies; 6+ messages in thread
From: Zhi Wang @ 2026-01-26 21:59 UTC (permalink / raw)
  To: rust-for-linux, linux-pci, linux-kernel
  Cc: dakr, aliceryhl, bhelgaas, kwilczynski, ojeda, alex.gaynor,
	boqun.feng, gary, bjorn3_gh, lossin, a.hindborg, tmgross,
	markus.probst, helgaas, cjia, smitra, ankita, aniketa, kwankhede,
	targupta, acourbot, joelagnelf, jhubbard, zhiwang, daniel.almeida,
	Zhi Wang

This RFC series introduces PCI capability discovery and access
infrastructure for Rust kernel drivers, with initial support for SR-IOV
(Single Root I/O Virtualization) capabilities.

Background
----------
Modern PCI devices expose advanced features through capability structures
in configuration space. Rust drivers need type-safe, ergonomic APIs to
discover and access these capabilities while maintaining the kernel's
existing safety guarantees. An example can be found in RFC patch. [1]

Overview
--------
Patch 1 extends ConfigSpace with fallible I/O methods that properly handle
PCI bus errors, providing the foundation for safe capability access with
runtime-determined offsets.

Patch 2 introduces the core capability infrastructure:
- Generic Capability<S, K> struct with Io trait implementation
- Capability size calculation using kernel's capability chaining
- SriovCapability wrapper for accessing VF configuration registers
- Support for reading VF Offset and VF BAR0/1/2 registers

Feedback Requested
------------------

1) The configuration cap doesn't have an fixed offset, thus it doesn't fit
with the infallible accessors. But to have fallible accessors, it needs the
config space backend to implement the fallible accessors as well. I tried
different approaches, this seems the most reasonable one. Any thought?

2) Capability traits hierarchy

I was thinking several solutions of arranging common functions for
Normal/Extended caps, all the extended caps. It seems a complicated traits
hierarchy again. Would like to hear more about this.

[1] https://lore.kernel.org/all/20251206124208.305963-5-zhiw@nvidia.com/

Zhi Wang (2):
  pci: Add fallible I/O methods to ConfigSpace
  pci: Add PCI capability infrastructure and SR-IOV capability support

 rust/kernel/pci.rs     |   9 ++
 rust/kernel/pci/cap.rs | 274 +++++++++++++++++++++++++++++++++++++++++
 rust/kernel/pci/io.rs  |  34 ++++-
 3 files changed, 314 insertions(+), 3 deletions(-)
 create mode 100644 rust/kernel/pci/cap.rs

-- 
2.51.0


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-02-05 13:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-26 21:59 [RFC 0/2] Rust PCI capability infrastructure and SR-IOV support Zhi Wang
2026-01-26 21:59 ` [RFC 1/2] pci: Add fallible I/O methods to ConfigSpace Zhi Wang
2026-01-26 21:59 ` [RFC 2/2] pci: Add PCI capability infrastructure and SR-IOV capability support Zhi Wang
2026-01-27 15:36   ` Gary Guo
2026-02-05 11:57     ` Zhi Wang
2026-02-05 13:10       ` Gary Guo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox