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

On Wednesday, September 08, 2010 03:44:38 pm Ram Pai wrote:
> On Wed, Sep 08, 2010 at 02:35:13PM -0600, Bjorn Helgaas wrote:

> > What specific problem are you solving?  Does this patch enable
> > us to assign resources to a device that previously had none?
> > A concrete example might help.
> 
> On machines with BIOS/uEFI that is unaware of SRIOV BARs, the BIOS/uEFI
> fails to allocate memory resources to the SRIOV BARs of PCIe functions.
> On such machines PCI-e Virtual functions cannot be enabled. 

I think you mean that an upstream bridge window might not be big
enough to assign SR-IOV BARs, so we might have to reassign peers
of the bridge so we can expand the window.  But a concrete example
would make this clear.

> Also on machines where BIOS/uEFI allocations conflict, the corresponding 
> devices are disabled.

What does it mean for BIOS allocations to conflict?  Two BARs that
claim the same space?  Is that a BIOS defect?

> This patch provides the user the ability to explicitly tell the kernel
> to try and allocate resources to such devices or resolve any conflicts.
> 
> By default the kernel disables all devices that have conflicting or no
> allocations.

> > > Signed-off-by: Ram Pai <linuxram@...ibm.com>
> > > 
> > > diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> > > index f084af0..eec068f 100644
> > > --- a/Documentation/kernel-parameters.txt
> > > +++ b/Documentation/kernel-parameters.txt
> > > @@ -1961,6 +1961,21 @@ and is between 256 and 4096 characters. It is defined in the file
> > >  				PAGE_SIZE is used as alignment.
> > >  				PCI-PCI bridge can be specified, if resource
> > >  				windows need to be expanded.
> > > +		override=[off, conflict, always, <device>]
> > > +				off : Do not override BIOS/firmware allocations. This is the 
> > > +					default
> > > +				conflict : override BIOS/firmware allocations if conflicting
> > > +					or not allocated.
> > > +				always : override all BIOS/firmware allocations
> > > +				<device>: Format [<domain>:]<bus>:<slot>.<func>[; ...]
> > > +					override BIOS/firmware allocations of specified
> > > +					devices
> > > +
> > > +		clear=<device>
> > > +				<device>: Format [<domain>:]<bus>:<slot>.<func>[; ...]
> > > +					release BIOS/firmware allocations of specified
> > > +					devices. By default no allocations are cleared.
> > 
> > I object in principle to new kernel parameters that users might need
> > to use just to get their box to work.  How would a user know that he
> > might need this option?  Isn't it possible for the kernel to figure
> > that out automatically?
> 
> The user can use these options only if he/she realizes that some devices are 
> disabled. These options are not needed in the normal case which is about 95% of
> the time. But I need these parameter to get my box working with SRIOV adapters.
> And I am sure they are needed for many other boxes that face similar issue.

I don't think this is a very convincing argument.  As a user, I don't
want to have to "realize some devices are disabled" and then grope
around for an option to fix things up.  As a vendor, I don't want to
have to mention stuff like this in release notes for machines that
might need it.

>From your other response:
> Well Yanghai's patch, git commit 977d17bb1749517b353874ccdc9b85abc7a58c2a,
> tried to automate the process. But it was error prone and caused regression.

Is it actually impossible to do it automatically, or did we just
not try hard enough?

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/