linux-kernel - Re: [RFC PATCH 1/1] PCI: Add Extended Tag + MRRS quirk for Xeon 6

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] [day] [month] [year] [list]

Message-ID: <67cb5c1ee3a98_1a7f29499@dwillia2-xfh.jf.intel.com.notmuch>
Date: Fri, 7 Mar 2025 12:50:38 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, "Bjorn
 Helgaas" <helgaas@...nel.org>
CC: Bjorn Helgaas <bhelgaas@...gle.com>, <linux-pci@...r.kernel.org>, LKML
	<linux-kernel@...r.kernel.org>, Dan Williams <dan.j.williams@...el.com>
Subject: Re: [RFC PATCH 1/1] PCI: Add Extended Tag + MRRS quirk for Xeon 6

Ilpo Järvinen wrote:
> On Tue, 4 Mar 2025, Bjorn Helgaas wrote:
> 
> > On Tue, Mar 04, 2025 at 03:51:08PM +0200, Ilpo Järvinen wrote:
> > > Disallow Extended Tags and Max Read Request Size (MRRS) larger than
> > > 128B for devices under Xeon 6 Root Ports if the Root Port is bifurcated
> > > to x2. Also, 10-Bit Tag Requester should be disallowed for device
> > > underneath these Root Ports but there is currently no 10-Bit Tag
> > > support in the kernel.
> > > 
> > > The normal path that writes MRRS is through
> > > pcie_bus_configure_settings() -> pcie_bus_configure_set() ->
> > > pcie_write_mrrs() and contains a few early returns that are based on
> > > the value of pcie_bus_config. Overriding such checks with the host
> > > bridge flag check on each level seems messy. Thus, simply ensure MRRS
> > > is always written in pci_configure_device() if a device requiring the
> > > quirk is detected.
> > 
> > This is kind of weird.  It's apparently not an erratum in the sense
> > that something doesn't *work*, just something for "optimized PCIe
> > performance"?
> > 
> > What are we supposed to do with this?  Add similar quirks for every
> > random PCI controller?  Scratching my head about what this means for
> > the future.
> > 
> > What bad things happen if we *don't* do this?  Is this something we
> > could/should rely on BIOS to configure for us?
> 
> Even if BIOS configures this (I'm under impression they already do, I 
> had problem in finding a configuration in our lab on which this patch
> had some effect). But my kernel was built with CONFIG_PCIE_BUS_DEFAULT, if 
> I set that to CONFIG_PCIE_BUS_PERFORMANCE, what BIOS did will be 
> overwritten.

The observation is that while linux only overrides Maximum Read Request
Size with PCIE_BUS_PERFORMANCE, it always overrides
PCI_EXP_DEVCTL_EXT_TAG.

> One option would be to drop the changes to drivers/pci/probe.c which is 
> there to force MRRS is always written (in this v1). That case should be 
> coverable with BIOS configuration but changes into pcie_set_readrq() seems 
> necessary to prevent Linux overwriting the configuration made by the BIOS. 
> Unless there's going to some other mechanism to tell kernel it should keep 
> hands from from these values as suggested by Dan.

The problem is determining when the BIOS has made an affirmative step to
limit the settings to defaults, vs expecting the OS to optimize the
settings because performance matters less in pre-OS runtime.