linux-kernel - Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not already assigned

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:	Thu, 13 May 2010 12:08:07 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Mike Travis <travis@....com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jacob Pan <jacob.jun.pan@...el.com>, Tejun Heo <tj@...nel.org>,
	Mike Habeck <habeck@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Yinghai <yinghai.lu@...cle.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not already
 assigned

On 05/13/2010 11:56 AM, Bjorn Helgaas wrote:
> 
> I'm a little bit nervous about Linux's current strategy of assigning
> resources to things before we even know whether we're going to use
> them.  We don't support dynamic PCI resource reassignment, so maybe
> we don't have any choice in this case, but generally I prefer the
> lazy approach.
> 

Lazy has its own pitfalls.  In particular, the issue here is about
allocation of bridge devices, which may cause all kinds of issues with
bridges further up.  Consider:

	       A
	      / \
             B   C
             |   |
             D   E

... where A, B, and C are bridges, and D and E are devices.  Now the
driver initializes D, and requests address space.  As a result, the OS
configures bridge B to have a 4K window, and accordingly the same for
bridge A.

Now you want to initialize device E.  This means the window for bridge A
has to be widened, because bridge C is going to need its own 4K window.
 If the linearly consecutive address space is not available, it now
means reconfiguring bridge B and device D.

4K granularity really hurts.  It made sense when bridges were relatively
rare, but in PCI-express world that is no longer the case...

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/