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]

Message-ID: <20100514170215.363d5121@virtuousgeek.org>
Date:	Fri, 14 May 2010 17:02:15 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Mike Travis <travis@....com>, Bjorn Helgaas <bjorn.helgaas@...com>,
	Mike Habeck <habeck@....com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Jacob Pan <jacob.jun.pan@...el.com>, Tejun Heo <tj@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Yinghai <yinghai.lu@...cle.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Myron Stowe <myron.stowe@...com>
Subject: Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not
 already assigned

On Fri, 14 May 2010 16:40:55 -0700
"H. Peter Anvin" <hpa@...or.com> wrote:

> On 05/14/2010 04:33 PM, Jesse Barnes wrote:
> > 
> > As for BIOS coordination for dynamic reallocation, yeah there'd be some
> > of that.  I think the basic principles would be:
> >   1) use BIOS allocations wherever possible
> >   2) get an accurate list of available resources from the BIOS for
> >      potential remapping later
> >   3) allocate resources for BARs and devices as late as possible (e.g.
> >      at driver bind time) to avoid allocating more than we need
> > 
> > But that's a good chunk of work, and as we've seen, PCs in particular
> > are really sensitive to having resources moved around too much, so step
> > (2) is probably the hardest part.
> > 
> 
> The real problem that I see, as outlined before, has nothing to do with
> the BIOS, but rather the interdependencies between resources.

I was using the term "BIOS" loosely to refer to safe ranges to allocate
resources.  Your topology example is a good one, there are definite
dependencies between devices, especially on large systems.  But in both
simple and complex cases, we still need to have resource ranges
available, or we'll have no where to put things at all.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/