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:   Mon, 9 Dec 2019 10:10:55 -0600
From:   Bjorn Helgaas <bjorn.helgaas@...il.com>
To:     Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, linux-pci@...r.kernel.org,
        linux-acpi@...r.kernel.org
Subject: Re: [[RFC PATCH v1] 0/1] Add pci=nobbn to ignore ACPI _BBN method to
 override host bridge bus window

On Thu, Nov 21, 2019 at 9:02 PM Nicholas Johnson
<nicholas.johnson-opensource@...look.com.au> wrote:
>
> Hi all,
>
> I want to be able to override the bus resource from ACPI, but nocrs does
> not do it. I am putting this out here to get a feel for the sentiment
> for doing something like this.

This should be cc'd to linus-pci and linux-acpi (added).  I only
noticed this message by accident.  And I don't see the patch at all.

> What is my motivation for doing this?
>
> I have a Gigabyte Z170X Designare motherboard which only gives resource
> [bus 00-7e]. I want the full [bus 00-ff] because I am trying to add as
> many Thunderbolt 3 ports with add-in cards as possible. Thunderbolt
> consumes bus numbers quickly. An Intel Ice Lake implementation (ideal)
> consumes 42 busses per port, but prior solutions consume 50 busses per
> port and have additional busses required for the NHI and USB
> controllers, as well as the bridges from the root port.
>
> Why not change nocrs to do this? Why the new kernel parameter?
>
> I imagine that on systems with multiple PCI root complexes, things will
> get hairy if we do this, if they are not placed on separate segments /
> domains by the firmware. I do not own such a beast, but from what I
> understand, the firmware normally places them on the same segment /
> domain with non-overlapping bus numbers. But we may still want to use
> nocrs for other reasons. I need to use nocrs to allow Linux to allocate
> vast amounts of MMIO and MMIO_PREF under the Thunderbolt root ports
> without the BIOS support for Thunderbolt. Hence, they should be kept
> separate.
>
> Why do this in general?
>
> The bus resource is still a resource which is specified from ACPI, just
> like those overridden by nocrs. Even if we do not use pci=nocrs to
> override it, it should be possible to override it, just as it is
> possible to override _CRS.

pci=nocrs is for working around defects in firmware or Linux.  The
firmware knows more about the platform than Linux, and in general we
have to trust it.  We probably should taint the kernel when we use it.

Any parameter like this should work the same on all ACPI systems,
including ia64 and arm64, and should probably also taint the kernel.

I can't see the patch itself, but I'm a little confused because we
normally get the bus number range from _CRS in acpi_pci_root_add() and
your patch doesn't appear to touch that.

> Nicholas Johnson (1):
>   PCI: Add pci=nobbn to ignore ACPI _BBN method to override host bridge
>     bus window
>
>  Documentation/admin-guide/kernel-parameters.txt |  2 ++
>  arch/x86/include/asm/pci_x86.h                  |  1 +
>  arch/x86/pci/acpi.c                             | 11 +++++++++++
>  arch/x86/pci/common.c                           |  3 +++
>  4 files changed, 17 insertions(+)
>
> --
> 2.24.0
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ