linux-kernel - Re: [PATCH RESEND v4 4/4] sample: rust: pci: add tests for config space routines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251104184245.2cc7e661.zhiw@nvidia.com>
Date: Tue, 4 Nov 2025 18:42:45 +0200
From: Zhi Wang <zhiw@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
CC: <rust-for-linux@...r.kernel.org>, <linux-pci@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <aliceryhl@...gle.com>,
	<bhelgaas@...gle.com>, <kwilczynski@...nel.org>, <ojeda@...nel.org>,
	<alex.gaynor@...il.com>, <boqun.feng@...il.com>, <gary@...yguo.net>,
	<bjorn3_gh@...tonmail.com>, <lossin@...nel.org>, <a.hindborg@...nel.org>,
	<tmgross@...ch.edu>, <markus.probst@...teo.de>, <helgaas@...nel.org>,
	<cjia@...dia.com>, <smitra@...dia.com>, <ankita@...dia.com>,
	<aniketa@...dia.com>, <kwankhede@...dia.com>, <targupta@...dia.com>,
	<acourbot@...dia.com>, <joelagnelf@...dia.com>, <jhubbard@...dia.com>,
	<zhiwang@...nel.org>
Subject: Re: [PATCH RESEND v4 4/4] sample: rust: pci: add tests for config
 space routines

On Tue, 04 Nov 2025 16:41:56 +0100
"Danilo Krummrich" <dakr@...nel.org> wrote:

> On Tue Nov 4, 2025 at 3:27 PM CET, Zhi Wang wrote:
> > +    fn config_space(pdev: &pci::Device<Core>) -> Result {
> > +        let config = pdev.config_space()?;
> > +
> > +        // TODO: use the register!() macro for defining PCI
> > configuration space registers once it
> > +        // has been move out of nova-core.
> > +        dev_info!(
> > +            pdev.as_ref(),
> > +            "pci-testdev config space read8 rev ID: {:x}\n",
> > +            config.read8(0x8)
> > +        );
> > +
> > +        dev_info!(
> > +            pdev.as_ref(),
> > +            "pci-testdev config space read16 vendor ID: {:x}\n",
> > +            config.read16(0)
> > +        );
> > +
> > +        dev_info!(
> > +            pdev.as_ref(),
> > +            "pci-testdev config space read32 BAR 0: {:x}\n",
> > +            config.read32(0x10)
> > +        );
> > +
> > +        dev_info!(
> > +            pdev.as_ref(),
> > +            "pci-testdev config space try_read8 rev ID: {:x}\n",
> > +            config.try_read8(0x8)?
> > +        );
> > +
> > +        dev_info!(
> > +            pdev.as_ref(),
> > +            "pci-testdev config space try_read16 vendor ID:
> > {:x}\n",
> > +            config.try_read16(0)?
> > +        );
> > +
> > +        dev_info!(
> > +            pdev.as_ref(),
> > +            "pci-testdev config space try_read32 BAR 0: {:x}\n",
> > +            config.try_read32(0x10)?
> > +        );
> 
> If we want to demonstrate the fallible accessors we should try
> accesses outside the bounds of the requested config space size.
> However, that doesn't really make sense, because in this case the
> driver could have been calling config_space_extended() instead.
> 
> So, I think the fallible versions don't really serve a purpose and we
> should probably drop them.

We can add them back if there is a use case in rust driver later.

Should I arrange the traits like below?

Io trait - Main trait + 32-bit access
 | 
 | -- Common address/bound checks
 |
 |	(accessor traits)
 | -- Io Fallible trait - (MMIO backend implements)
 | -- Io Infallible trait - (MMIO/ConfigSpace backend implements this)
 |
 | -- Io64 trait - For backend supports 64 bit access
	   |      (accessor traits)
           | -- Io64 Faillable trait (MMIO backend implements this)
	   | -- Io64 Infallible trait (MMIO backend implements this)

I am also thinking if we should keep 64-bit access accessor in the
backend implementation instead in the Io trait (like {read, write}
_relaxed), because I think few backend (PCI Config Space/I2C/SPI) would
support 64-bit atomic access except MMIO backend.

Z.