Re: [RFC PATCH 1/1] PCI: override BIOS/firmware resource allocation

From: Bjorn Helgaas
Date: Wed Sep 08 2010 - 19:12:36 EST


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@xxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/