linux-kernel - Re: [PATCH v2] pci/aspm: Remove CONFIG_PCIEASPM

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180730141428.GK173328@bhelgaas-glaptop.roam.corp.google.com>
Date:   Mon, 30 Jul 2018 09:14:28 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Sinan Kaya <okaya@...nel.org>
Cc:     Rajat Jain <rajatja@...gle.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Keith Busch <keith.busch@...el.com>,
        Vidya Sagar <vidyas@...dia.com>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Kees Cook <keescook@...omium.org>,
        "Gustavo A. R. Silva" <garsilva@...eddedor.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Sinan Kaya <okaya@...eaurora.org>,
        Frederick Lawler <fred@...dlawl.com>,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        mayurkumar.patel@...el.com, rajatxjain@...il.com,
        Richard Hughes <rhughes@...hat.com>,
        Carlos Garnacho <cgarnach@...hat.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Pali Rohar <pali.rohar@...il.com>,
        Takashi Iwai <tiwai@...e.de>,
        Andy Whitcroft <apw@...onical.com>,
        Colin Ian King <colin.king@...onical.com>
Subject: Re: [PATCH v2] pci/aspm: Remove CONFIG_PCIEASPM_DEBUG

On Sat, Jul 28, 2018 at 05:16:13PM -0700, Sinan Kaya wrote:
> On 7/27/2018 1:26 PM, Bjorn Helgaas wrote:
> > - A link can lead to a multi-function device, and the spec allows
> >      those functions to have different ASPM settings (see PCIe r4.0,
> >      sec 5.4.1).  With the sysfs files at the upstream end of the link,
> >      we have no way to configure those functions individually.
> 
> Even though we can set them individually, there is only one PCIe link
> for single function as well as multi-function devices.
> 
> It would be a user mistake to allow individual PCIe functions with
> different ASPM policies. (maybe, we should enforce it if we are not
> doing it already).

It's true that multi-function devices share a single PCIe link.

However, the end of sec 5.4.1 does make it clear that the functions
need not have the same ASPM configuration, and it gives rules for how
those different settings should affect the shared link.  Since it
mentions different ASPM Control fields for the different functions, I
assume the policy combining those per-function settings into the
single link behavior must be implemented in the hardware.

Obviously we don't support per-function ASPM settings today.  I don't
know whether there's any value in supporting them or not, but putting
the control files at the upstream end basically precludes us from ever
supporting them.

Bjorn