linux-kernel - Re: [PATCH v6 0/4] PCI: Patch series to support Thunderbolt without any BIOS support

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]

Date:   Sat, 15 Jun 2019 14:56:19 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
        "corbet@....net" <corbet@....net>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Logan Gunthorpe <logang@...tatee.com>
Subject: Re: [PATCH v6 0/4] PCI: Patch series to support Thunderbolt without
 any BIOS support

[+cc Ben, Logan]

Ben, Logan, since you're looking at the resource code, maybe you'd be
interested in this as well?

On Wed, May 22, 2019 at 02:30:30PM +0000, Nicholas Johnson wrote:
> Rebase patches to apply cleanly to 5.2-rc1 source. Remove patch for 
> comment style cleanup as this has already been applied.

Thanks for rebasing these.

They do apply cleanly, but they seem to be base64-encoded MIME
attachments, and I don't know how to make mutt extract them easily.  I
had to save each patch attachment individually, apply it, insert the
commit log manually, etc.

Is there any chance you could send the next series as plain-text
patches?  That would be a lot easier for me.

> Anybody interested in testing, you can do so with:
> 
> a) Intel system with Thunderbolt 3 and native enumeration. The Gigabyte 
> Z390 Designare is one of the most perfect for this that I have never had 
> the opportunity to use - it does not even have the option for BIOS 
> assisted enumeration present in the BIOS.
> 
> b) Any system with PCIe and the Gigabyte GC-TITAN RIDGE add-in card, 
> jump the header as described and use kernel parameters like:
> 
> pci=assign-busses,hpbussize=0x33,realloc,hpmemsize=128M,hpmemprefsize=1G,nocrs 
> pcie_ports=native
> 
> [optional] pci.dyndbg
> 
>     ___
>  __/   \__
> |o o o o o| When looking into the receptacle on back of PCIe card.
> |_________| Jump pins 3 and 5.
> 
>  1 2 3 4 5
> 
> The Intel system is nice in that it should just work. The add-in card 
> setup is nice in that you can go nuts and assign copious amounts of 
> MMIO_PREF - can anybody show a Xeon Phi coprocessor with 16G BAR working 
> in an eGPU enclosure with these patches?
> 
> However, if you specify the above kernel parameters on the Intel system, 
> you should be able to override it to allocate more space.
> 
> Nicholas Johnson (4):
>   PCI: Consider alignment of hot-added bridges when distributing
>     available resources
>   PCI: Modify extend_bridge_window() to set resource size directly
>   PCI: Fix bug resulting in double hpmemsize being assigned to MMIO
>     window
>   PCI: Add pci=hpmemprefsize parameter to set MMIO_PREF size
>     independently
> 
>  .../admin-guide/kernel-parameters.txt         |   7 +-
>  drivers/pci/pci.c                             |  18 +-
>  drivers/pci/setup-bus.c                       | 265 ++++++++++--------
>  include/linux/pci.h                           |   3 +-
>  4 files changed, 167 insertions(+), 126 deletions(-)
> 
> -- 
> 2.20.1
>