linux-kernel - RE: mach-socfpga: PCIe Root IO TLP support for Cyclone V

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: <531d4fadcc694f9582af54f3998720b4@AcuMS.aculab.com>
Date:   Mon, 6 Nov 2023 11:02:12 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'David Epping' <david.epping@...singlinkelectronics.com>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Krzysztof Wilczyński <kw@...ux.com>
Subject: RE: mach-socfpga: PCIe Root IO TLP support for Cyclone V

From: David Epping
> Sent: 06 November 2023 10:15
> 
> On Sun, Nov 05, 2023 at 11:20:03AM +0000, David Laight wrote:
...
> > If you are building the FPGA image then all the logic to convert the
> > memory mapped slave cycles (into the fpga logic) is supplied as
> > verilog source.
> 
> The CPU subsystem and the PCIe IP are hard IP in silicon and can not be altered.

If you look carefully you'll find that the 'hard IP' block stops
with a streaming interface that carries the data TLP.
All the logic to convert the TLP into Avalon memory cycles is verilog source.
So, at least in principle, it is modifiable.

With a bit of effort it is possible to trace the TLP into fpga memory.
(We had to modify the verilog to expose the TX TLP.)
Even allowing for development time it was probably cheaper than
buying a PCIe monitor!

> They are connected via the FPGA logic, though, and I agree one approach could be to intercept their
> communication with custom HDL.
> However, Linux uses the exact same PCIe hard IP registers required for IO TLPs to send Config TLPs.
> Every TLP requires multiple accesses to multiple registers, so locking between FPGA logic and Linux
> transactions would be required.
> I'm not saying that this is impossible, but I don't think it can be robust without a Linux software
> change.
> A software only solution has the benefit of being available to all users of such an FPGA, without
> access to that special logic.

I saw/checked you'd added a lock, didn't see it was the same one used
for config space accesses.

> > I thought that all recent endpoints were required [1] to work with
> > just memory BARs - even going back to the later PCI versions.
> > So I'm surprised a PCIe endpoint need an IO BAR.
> 
> The AX99100 implements a so called "Legacy Endpoint" and is thus allowed to
> rely on support for IO space.
> I guess this choice was made to stay driver-compatible to the PCI version,
> although I don't know the ancestry if this product.

A lot of PCI devices solved this by adding a memory BAR that
mapped exactly the same registers.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)