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: <20100514160651.2b4ee3d7@virtuousgeek.org>
Date:	Fri, 14 May 2010 16:06:51 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Mike Travis <travis@....com>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>, Mike Habeck <habeck@....com>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, 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 15:59:11 -0700
Mike Travis <travis@....com> wrote:

> 
> 
> Jesse Barnes wrote:
> > On Fri, 14 May 2010 15:34:01 -0700
> > Mike Travis <travis@....com> wrote:
> > 
> >>
> >> Jesse Barnes wrote:
> >>> On Thu, 13 May 2010 14:02:30 -0600
> >>> Bjorn Helgaas <bjorn.helgaas@...com> wrote:
> >>>>>> This issue is not specific to x86, so I don't really like having
> >>>>>> the implementation be x86-specific.
> >>>>> I agree this isn't a x86 specific issue but given the 'norom'
> >>>>> cmdline option is basically doing the same thing (but for pci
> >>>>> Expansion ROM BARs) this code was modeled after it.
> >>>> IMHO, we should fix both.
> >>> Yeah, that would be good.  Mike, have you looked at this at all?
> >>>
> >>> Also, to clarify, this isn't affecting users today, right?  Or do you
> >>> need all this I/O space for multiple IOHs and the drivers that bind to
> >>> them in current UV systems?
> >> We have customers that want to install more than 16 PCI-e cards right
> >> now.  Our window of opportunity closes very soon (days), so either this
> >> patch makes it in as is (or something close), or we wait for another
> >> release cycle.  UV shipments start this month.
> >>
> >> [I wouldn't mind working on an improvement for later.]
> > 
> > Wow and they're using cards that want to use I/O space?  Funky.  It's
> > too late to get this into 2.6.34, but that can't be what you were
> > expecting... I don't see a problem with getting something like this in
> > for 2.6.35.
> 
> 2.6.35 would be fine.  It's the acceptance that's the key.
> 
> And yes, we're using standard cards like everyone else... ;-)
> 
> [The message is "UV" is just a really, really big PC. ;-)]
> 
> I would appreciate however, some more detail on what's the goal of the
> updates to "fix both".  Thanks!

As Bjorn noted, both the norom and nobar options are listed as x86
specific in the documentation and use x86 specific flags and code to
prevent their respective allocations.

It would be good if we could move the flags and code to the common PCI
layer in drivers/pci so that other arches could take advantage of it,
and we could have less resource management fragmentation.

-- 
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/