linux-kernel - Re: [RFC v2 PATCH 1/1] PCI: override BIOS/firmware resource allocation

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:	Fri, 22 Oct 2010 11:55:18 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Ram Pai <linuxram@...ibm.com>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, clemens@...isch.de,
	Yinghai Lu <yinghai@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC v2 PATCH 1/1] PCI: override BIOS/firmware resource allocation

On Thursday, October 21, 2010 06:28:51 pm Ram Pai wrote:
> On Tue, Oct 19, 2010 at 11:24:39AM -0700, Jesse Barnes wrote:

> Ok. After further investigation, I find that the BIOS has not allocated any
> resource to hotplug bridges that have no devices behind them. However
> the OS tries to allocate some minimal resources, 4096 I/O ports and 2M mem
> window, to the these hotplug bridges but fails because there are not enough
> resources to satisfy all the hotplug bridges.
> 
> This issue exists even today with the latest mainline kernel but is masked
> because no devices are really effected. However Yinghai's reallocation patch
> exposed the issue, since it released the BIOS allocated window and tried to
> reallocate. Unfortunately it ended up allocating in the wrong order. The
> bridges with real devices got no resources, where as the hotplug bridges with
> no devices got some mimimal resources.
> 
> The details are captured at: https://bugzilla.kernel.org/show_bug.cgi?id=15960
> 
> I suppose the solution is to not pre-allocate resources to hotplug bridges that
> have no devices behind them, and then bring back Yinghai's reallocation patch.  

If we assign resources to bridges with no devices behind them while
starving bridges that DO have devices behind them, I think that's a bug.
It'd be great if you could isolate and fix that before we complicate
things by throwing Yinghai's patch into the mix.

I think it'd interesting to have a debug parameter like "pci=assign-all"
that meant "ignore all BIOS PCI config and start from scratch."  I'm
sure we'd trip over lots of issues and it would be easier to resolve them
before trying to make things fancier.

> > So on that note, does Windows on these machines support allocation of
> > SRIOV resources?  If so, how is it handled?  Which resource ranges are
> > used for the extra BARs?
> 
> No. I have not tried windows on these boxes. But last I heard windows
> did not support SRIOV. Does it?

I've heard anecdotally that Windows supports SRIOV much better than
Linux does, but I have no evidence.  I would guess that it depends on
driver support in addition to Windows itself.

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